企业官网建设流程全解析

1. 被忽略的“另一半”：自适应阈值到底在做什么

如果你写过OpenCV的图像处理代码，大概率用过cv2.adaptiveThreshold这个函数。它的参数列表看起来不复杂：输入图像、最大灰度值、自适应方法、阈值类型、邻域块大小、常数C。很多人调参的日常就是改blockSize和C，看着二值化结果一点点变化，觉得差不多了就收工。

但标题里那句话——“自适应阈值调了三年，可能一直在调错那一边”——说的不是blockSize或C调错了，而是THRESH_BINARY和THRESH_BINARY_INV这两个阈值类型，很多人从头到尾就没认真想过自己该用哪个。

先把这个函数的核心逻辑捋一遍。adaptiveThreshold做的事情是：对图像中每一个像素，以它为中心取一个blockSize × blockSize的邻域，计算这个邻域内的阈值（均值或高斯加权均值），然后用这个局部阈值来判断当前像素是“亮”还是“暗”。关键在于，判断完之后输出什么值，取决于thresholdType。

THRESH_BINARY的规则是：像素值大于局部阈值，输出maxValue（通常是255），否则输出0。THRESH_BINARY_INV则反过来：像素值大于局部阈值，输出0，否则输出maxValue。

看起来只是黑白颠倒了一下，但在实际项目里，这个选择直接决定了你后续所有处理步骤的输入是什么。我见过太多人，拿到一张图，随手写了THRESH_BINARY，然后开始疯狂调blockSize和C，调了半天觉得效果不对，又去换自适应方法，从ADAPTIVE_THRESH_MEAN_C换到ADAPTIVE_THRESH_GAUSSIAN_C，还是不满意。问题根本不在那些参数上，而在于他想要的前景和背景，跟函数默认输出的黑白关系是反的。

举个具体的例子。假设你在做一个文档扫描的项目，拍了一张白纸黑字的照片，想提取文字。文字是暗的，纸是亮的。用THRESH_BINARY，局部阈值算出来大概在纸和字之间，那么纸（亮）大于阈值，输出255；字（暗）小于阈值，输出0。结果就是白底黑字，文字是黑色的前景。这看起来没问题。

但如果你做的是车牌识别，车牌上的字符通常是亮色（白字），背景是暗色（蓝底或黑底）。这时候用THRESH_BINARY，字符（亮）大于阈值输出255，背景（暗）输出0，结果就是白字黑底。如果你后续的轮廓查找或者字符分割算法假设的是“黑底白字”，那你就得用THRESH_BINARY_INV把结果反过来。

问题在于，很多人根本不清楚自己的后续算法到底假设的是哪种极性。他们只是看到二值化结果“看起来还行”，就继续往下写了。等到轮廓查找出来一堆乱七八糟的东西，或者字符分割总是切错位置，才开始回头怀疑二值化。这时候如果还是只盯着blockSize和C调，那就是在错误的方向上越走越远。

一个简单的自检方法：把你的二值化结果打印出来，看看你关心的目标区域是白色（255）还是黑色（0）。然后问自己一句：我后面的算法，是希望目标区域为白，还是为黑？如果答案跟当前输出不一致，先改thresholdType，再调其他参数。

这个逻辑听起来简单到不值一提，但我在实际项目里见过的翻车案例，至少有一半跟这个有关。原因也很真实：THRESH_BINARY是默认值，很多人写代码的时候根本不看参数列表，直接抄了个示例，示例里用的是THRESH_BINARY，他就一直用下去了。三年下来，他可能换了十几套blockSize和C的组合，却从来没试过把那个参数改成THRESH_BINARY_INV。

2. 为什么“调错边”这件事如此普遍

2.1 默认参数的惯性陷阱

OpenCV的adaptiveThreshold函数签名里，thresholdType是一个必填参数，没有默认值。但在大量的教程、示例代码和Stack Overflow回答里，THRESH_BINARY出现的频率远高于THRESH_BINARY_INV。这导致一个很自然的后果：新手在模仿学习的时候，几乎总是从THRESH_BINARY开始。

更麻烦的是，很多教程为了演示效果，会选一张本身就适合THRESH_BINARY的图片。比如一张光照不均的文档照片，用THRESH_BINARY处理后白底黑字，看起来非常“正确”。读者跟着做了一遍，效果不错，就记住了这个组合。等到自己遇到新场景，比如暗背景亮目标的图像，他还是用同样的参数，结果出来一片黑或者一片白，然后就开始怀疑是blockSize不对。

我自己的习惯是，在写任何二值化代码之前，先花30秒做一件事：把原图和三通道的灰度图都显示出来，用鼠标在目标区域和背景区域各取几个像素值，心里有个大概的数。然后根据“目标应该是什么颜色”来决定用哪个thresholdType。这个习惯帮我省掉了无数次无意义的调参时间。

2.2 对“前景”和“背景”的认知模糊

另一个深层原因是，很多人对“前景”和“背景”的定义本身就是模糊的。在图像处理里，前景通常指你感兴趣的目标区域，背景指你不关心的区域。但“感兴趣”这件事，在不同任务里含义完全不同。

做缺陷检测的时候，缺陷是前景，正常区域是背景。做文字识别的时候，文字是前景，纸张是背景。做细胞计数的时候，细胞是前景，培养皿是背景。这些场景里，前景有时候是亮的，有时候是暗的。如果你不先把这个问题想清楚，就没办法确定thresholdType该用哪个。

我见过一个做PCB板缺陷检测的工程师，他的任务是找出板子上的划痕。划痕在图像里表现为暗色的细线，板子本身是亮色的。他一开始用THRESH_BINARY，结果划痕变成了黑色，板子变成了白色。然后他用findContours去找轮廓，RETR_EXTERNAL模式下找到的是整个板子的外轮廓，因为板子是白色的连通区域。他花了很久去调blockSize，想让划痕“更明显”，但方向完全错了。后来改成THRESH_BINARY_INV，划痕变成白色，板子变成黑色，findContours一下子就找到了那些细线状的轮廓。

这个案例里，他的后续算法（轮廓查找）假设的是“前景为白”。而他的前景（划痕）在原图里是暗的。所以必须用THRESH_BINARY_INV把暗的前景翻成白色。如果他一直用THRESH_BINARY，那不管怎么调blockSize和C，划痕永远是黑色，轮廓查找永远找的是背景。

2.3 自适应阈值与全局阈值的混淆

还有一个常见的混淆点：把adaptiveThreshold和threshold搞混。全局阈值cv2.threshold里，THRESH_BINARY和THRESH_BINARY_INV的语义是明确的：大于阈值的像素设为maxValue，否则为0（或反过来）。因为全局阈值只有一个阈值，所以“大于”和“小于”的关系很直观。

但自适应阈值里，每个像素的阈值都不一样。这时候“大于局部阈值”这个判断，在不同区域可能有不同的含义。比如在暗区域，局部阈值可能很低，像素值稍微高一点就“大于”了；在亮区域，局部阈值很高，像素值要很高才“大于”。这种局部性让THRESH_BINARY和THRESH_BINARY_INV的选择变得更加微妙。

我个人的经验是：不要试图在脑子里推演每个像素的判断结果。直接跑一遍，把两种thresholdType的结果都显示出来，肉眼对比。哪个结果里你的目标区域是白色，就用哪个。这个方法虽然笨，但绝对可靠。

3. 一个完整的实操案例：从选错到选对

3.1 场景描述与初始错误

假设我们要处理一批工业零件表面的字符识别任务。零件是金属材质，表面经过拉丝处理，字符是激光雕刻的，比周围区域略暗。图像整体光照不均匀，左侧偏亮，右侧偏暗。目标是提取字符区域，送给后续的OCR模块。

初始代码大概长这样：

import cv2 import numpy as np img = cv2.imread('part.png', cv2.IMREAD_GRAYSCALE) binary = cv2.adaptiveThreshold( img, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 11, 2 ) cv2.imshow('binary', binary) cv2.waitKey(0)

跑出来的结果：字符区域是黑色的，背景是白色的。因为字符比周围暗，小于局部阈值，THRESH_BINARY输出0（黑色）。背景大于阈值，输出255（白色）。

然后我们把这个结果送给OCR。OCR模块的预处理假设是“黑底白字”，也就是字符应该是白色的前景。结果它拿到的是白底黑字，识别率惨不忍睹。这时候如果去调blockSize和C，字符的粗细会变，但黑白关系不会变。调再久也没用。

3.2 正确的参数选择过程

正确的做法是，先明确OCR模块需要什么。假设它需要“黑底白字”，那么字符必须是白色（255），背景必须是黑色（0）。原图中字符是暗的，背景是亮的。要让暗的字符变成白色，就需要用THRESH_BINARY_INV：像素值小于局部阈值时输出maxValue（255），大于时输出0。

修改后的代码：

binary = cv2.adaptiveThreshold( img, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY_INV, 11, 2 )

这时候字符变成白色，背景变成黑色。OCR的识别率立刻上来了。

但事情还没完。blockSize=11和C=2这两个参数，在THRESH_BINARY_INV下的表现和之前完全不同。因为现在输出极性反了，C的符号意义也变了。在THRESH_BINARY下，C是“从均值里减去的常数”，用来微调阈值。在THRESH_BINARY_INV下，同样的C值，效果是反的。所以改完thresholdType之后，blockSize和C需要重新调。

我一般的调参顺序是：

1. 先固定C=0，只调blockSize。从3开始，逐步增加到5、7、9、11、15、21。观察字符的连通性和背景的干净程度。blockSize太小，字符内部会出现空洞；太大，局部适应性变差，光照不均的区域处理不好。
2. blockSize确定后，再微调C。C为正数时，阈值降低，更多像素被判定为“大于阈值”（在THRESH_BINARY_INV下就是更多像素变成黑色）。C为负数时相反。通常C在-5到5之间调整。
3. 如果ADAPTIVE_THRESH_GAUSSIAN_C效果不好，再换ADAPTIVE_THRESH_MEAN_C试试。高斯加权对噪声更鲁棒，但计算稍慢；均值更简单，对细小的字符可能更敏感。

这个案例里，最终blockSize=15，C=3，THRESH_BINARY_INV，效果最好。字符清晰，背景干净，OCR识别率从之前的60%提升到95%以上。

3.3 参数对比表格

为了更直观地展示thresholdType的影响，我整理了一个对比表：

这个表里最值得注意的是第二行和第三行的对比。同样是用THRESH_BINARY_INV，blockSize和C没调好的时候，识别率只有75%。这说明改对thresholdType只是第一步，后续的参数微调同样重要。但如果没有第一步，后面调得再好也白搭。

4. 常见问题与排查技巧实录

4.1 二值化结果全黑或全白

这是最典型的问题。原因通常有两个：一是thresholdType选反了，二是C值极端了。

排查步骤：

1. 先检查thresholdType。把THRESH_BINARY和THRESH_BINARY_INV都跑一遍，看哪个结果里有你想要的图案。如果两个都是全黑或全白，那问题不在thresholdType。
2. 检查C值。如果C设得非常大（比如100），在THRESH_BINARY下几乎所有像素都小于阈值，输出全黑。在THRESH_BINARY_INV下几乎所有像素都大于阈值，也输出全黑。把C改回0或小数值再试。
3. 检查输入图像的数据类型。adaptiveThreshold要求输入是8位单通道图像（CV_8UC1）。如果你传的是彩色图或者16位图，函数会报错或者产生奇怪的结果。用img.dtype确认一下。
4. 检查blockSize。必须是大于1的奇数。如果传了偶数，OpenCV会报错。如果传了1，邻域只有一个像素，阈值就是像素本身，结果会非常奇怪。

我个人的习惯是，在调参之前先写一个小的调试脚本，把原图、灰度图、两种thresholdType的结果拼成一张大图显示出来。这样一眼就能看出问题在哪，比反复改代码跑一遍快得多。

4.2 字符或目标区域出现断裂

二值化后，原本连通的字符断成了几截，或者目标区域的边缘变得支离破碎。这通常是blockSize太小导致的。

blockSize决定了局部阈值的计算范围。如果blockSize太小，比如3或5，那么每个像素的阈值只由周围很少的像素决定。在字符边缘，局部阈值可能突然变化，导致边缘像素被错误分类。增大blockSize可以让阈值更平滑，但太大又会让局部适应性变差。

我的经验值是：对于字符识别任务，blockSize通常在11到21之间。对于更大的目标（比如细胞、零件），可以到31或51。具体值需要根据目标在图像中的实际像素尺寸来定。一个粗略的估算方法是：blockSize大约等于目标宽度的1/3到1/2。比如字符宽度约30像素，blockSize取11到15比较合适。

4.3 背景噪声太多

二值化后，背景里出现了很多细小的白色噪点（在THRESH_BINARY_INV下）。这通常是因为C值太小或者为负，导致阈值偏低，背景中稍微亮一点的像素就被误判为目标。

解决方法：

1. 增大C值。在THRESH_BINARY_INV下，增大C会让阈值降低，更多像素被判定为“小于阈值”，也就是变成白色。等等，这里需要仔细想一下。adaptiveThreshold的公式是：T(x,y) = mean(blockSize) - C（对于THRESH_BINARY）。在THRESH_BINARY_INV下，判断条件是src(x,y) > T(x,y)时输出0，否则输出255。所以增大C会让T变小，src > T的条件更容易满足，更多像素输出0（黑色）。也就是说，在THRESH_BINARY_INV下，增大C会让背景更黑，噪点更少。这个逻辑我一开始也搞反过，后来用一个小图实测了一下才确认。
2. 如果增大C后目标区域也被侵蚀了，那就需要先做去噪。用cv2.medianBlur或cv2.GaussianBlur对原图做一次平滑，再送进adaptiveThreshold。中值滤波对椒盐噪声特别有效，高斯滤波对高斯噪声更合适。
3. 如果噪点是结构性的（比如金属表面的纹理），可以考虑在二值化之后做形态学开运算，用一个小尺寸的矩形核把细小的噪点去掉。

4.4 光照不均导致局部失效

自适应阈值的优势就是能处理光照不均，但它也不是万能的。如果光照变化太剧烈，比如图像一半极亮一半极暗，blockSize再大也救不回来。

这时候可以考虑分区域处理：把图像分成几个子区域，每个子区域单独做自适应阈值，然后再拼接。或者先用cv2.createCLAHE做限制对比度自适应直方图均衡化，把光照拉平一些，再送进adaptiveThreshold。

我试过一个更粗暴的方法：对图像做一次大尺度的高斯模糊，得到一个“光照背景图”，然后用原图减去这个背景图，再做自适应阈值。这个方法在文档扫描里效果很好，能有效消除阴影和光照梯度。

4.5 常见问题速查表

5. 更深一层：自适应阈值的数学原理与参数计算

5.1 均值法与高斯法的区别

ADAPTIVE_THRESH_MEAN_C计算的是邻域内所有像素的算术平均值。ADAPTIVE_THRESH_GAUSSIAN_C计算的是邻域内像素的高斯加权平均值，权重由像素到中心点的距离决定，距离越近权重越大。

这个区别在实际效果上表现为：高斯法对中心像素更敏感，边缘过渡更平滑；均值法对所有像素一视同仁，在纹理丰富的区域可能产生更硬的边缘。

选择哪个，取决于你的目标特性。如果目标是细小的、边缘锐利的结构（比如文字笔画），高斯法通常更好。如果目标是较大的、边缘模糊的区域（比如细胞团），均值法可能更合适。

5.2 blockSize的数学约束

blockSize必须是奇数，且大于1。为什么必须是奇数？因为要以当前像素为中心取一个对称的邻域。如果blockSize是偶数，邻域的中心就不在像素格点上，OpenCV会直接报错。

blockSize的最小值是3，对应3×3邻域。最大值没有硬性限制，但不能超过图像尺寸。如果blockSize大于图像尺寸，OpenCV会报错。

从计算量来看，blockSize越大，每个像素需要处理的邻域像素越多，耗时越长。对于实时应用，blockSize通常不超过21。对于离线处理，可以适当放宽。

5.3 C值的符号与大小

C是一个从均值中减去的常数。在THRESH_BINARY下，阈值T = mean - C。C为正时，阈值降低，更多像素被判定为“大于阈值”，输出maxValue。C为负时，阈值升高，更少像素输出maxValue。

在THRESH_BINARY_INV下，判断条件反过来了，所以C的效果也反过来。C为正时，阈值降低，更多像素被判定为“大于阈值”，输出0（黑色）。C为负时，更多像素输出maxValue（白色）。

这个符号关系很容易搞混。我的建议是：不要死记硬背，直接跑一个小实验。取一张简单的测试图，固定blockSize，把C从-10到10每隔2取一个值，把结果拼成一张网格图。看一眼就全明白了。

5.4 一个实用的参数搜索脚本

与其手动一个个试，不如写个脚本自动生成参数网格：

import cv2 import numpy as np img = cv2.imread('test.png', cv2.IMREAD_GRAYSCALE) block_sizes = [5, 9, 15, 21, 31] c_values = [-5, -2, 0, 2, 5] threshold_types = [cv2.THRESH_BINARY, cv2.THRESH_BINARY_INV] results = [] for tt in threshold_types: for bs in block_sizes: for c in c_values: binary = cv2.adaptiveThreshold( img, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, tt, bs, c ) # 这里可以加一个评分函数，比如计算目标区域的连通性 # 或者直接保存下来人工看 cv2.imwrite(f'result_tt{tt}_bs{bs}_c{c}.png', binary)

跑完这个脚本，你会得到一堆图片。快速浏览一遍，把明显不对的排除掉，剩下的再仔细对比。这个方法比在代码里反复改参数高效得多。

6. 从二值化到后续处理的衔接

6.1 轮廓查找的极性假设

cv2.findContours在OpenCV 3.x之后，RETR_EXTERNAL模式只返回最外层的轮廓。如果你的二值化结果里，目标区域是白色，背景是黑色，那么findContours找到的就是目标的轮廓。如果极性反了，目标区域是黑色，背景是白色，那么findContours找到的是整个背景的轮廓，或者根本找不到你想要的轮廓。

这就是为什么thresholdType的选择必须和后续算法匹配。很多人写代码是线性的：先二值化，再找轮廓，再筛选。但他们在写二值化的时候，脑子里想的是“把图像变成黑白”，而不是“把目标变成白色”。这个思维上的细微差别，导致了后面一连串的问题。

6.2 形态学操作的极性依赖

cv2.morphologyEx里的腐蚀和膨胀操作，对前景和背景的定义也是依赖极性的。腐蚀操作会侵蚀白色区域（在前景为白的情况下），膨胀会扩张白色区域。如果你的二值化结果里目标区域是黑色，那么腐蚀和膨胀的效果就完全反了。

我见过一个案例，有人用THRESH_BINARY处理了一张暗背景亮目标的图，目标变成了黑色。然后他用cv2.erode想去除噪点，结果目标区域被“腐蚀”得更小了，因为腐蚀操作默认侵蚀的是白色区域。他调了半天核的大小，觉得腐蚀效果不对，最后才发现是极性反了。

6.3 连通域分析的极性影响

cv2.connectedComponents默认把白色区域当作前景。如果你的目标区域是黑色，那么连通域分析会把背景当作一个巨大的连通域，而目标区域被忽略。这时候要么改thresholdType，要么在调用connectedComponents之前用cv2.bitwise_not把图像反转一下。

cv2.bitwise_not是一个很实用的函数，可以把二值图像的黑白完全反转。如果你不确定后续算法需要什么极性，可以在二值化之后加一行binary = cv2.bitwise_not(binary)，看看效果。但更好的做法是在adaptiveThreshold里直接选对thresholdType，少一次操作，少一次出错的机会。

7. 我踩过的坑与经验总结

第一个坑是“默认值惯性”。我早期写代码的时候，THRESH_BINARY几乎是肌肉记忆，根本不过脑子。直到有一次做暗背景亮目标的检测，调了一下午参数都不对，最后同事看了一眼说“你试试INV”，一改就对了。从那以后，我养成了一个习惯：每次写adaptiveThreshold之前，先问自己一句“我的目标是亮的还是暗的，后续算法要的是白的还是黑的”。

第二个坑是“参数联动”。改thresholdType之后，blockSize和C的最优值会变。我一开始不知道这个，改完极性发现效果还是不对，以为改错了，又改回去。后来才明白，极性变了，阈值的计算和判断逻辑都变了，参数当然要重新调。现在我的流程是：先定极性，再调blockSize，最后微调C。顺序不能乱。

第三个坑是“忽略输入图像的质量”。adaptiveThreshold对噪声很敏感。如果原图噪声大，二值化结果会非常碎。我现在的习惯是，在二值化之前先做一次cv2.medianBlur(img, 3)或cv2.GaussianBlur(img, (3,3), 0)。这个预处理步骤花不了多少时间，但能显著提升二值化的稳定性。

第四个坑是“blockSize的奇偶性”。有一次我传了个blockSize=10，OpenCV直接报错。我查了半天文档才发现必须是奇数。后来我写了一个小函数，自动把偶数转成最近的奇数：

def ensure_odd(n): return n if n % 2 == 1 else n + 1

这个函数虽然简单，但省去了不少调试时间。

第五个坑是“C值的符号”。在THRESH_BINARY下，增大C会让更多像素变白。在THRESH_BINARY_INV下，增大C会让更多像素变黑。这个关系我搞反过好几次，后来干脆不记了，每次都用小图实测一下。实测比记忆可靠。

8. 一个可复用的自适应阈值调参模板

基于上面的经验，我整理了一个调参模板，可以直接套用到大多数场景：

import cv2 import numpy as np def adaptive_threshold_tune(img_path, target_is_bright=True, target_should_be_white=True): """ img_path: 输入图像路径 target_is_bright: 目标在原图中是亮色(True)还是暗色(False) target_should_be_white: 后续算法需要目标为白色(True)还是黑色(False) """ img = cv2.imread(img_path, cv2.IMREAD_GRAYSCALE) # 预处理：去噪 img_blur = cv2.medianBlur(img, 3) # 决定thresholdType if target_is_bright == target_should_be_white: tt = cv2.THRESH_BINARY else: tt = cv2.THRESH_BINARY_INV # 参数搜索 best_score = -1 best_params = None for bs in [5, 7, 9, 11, 15, 21, 31]: for c in [-5, -3, -1, 0, 1, 3, 5]: binary = cv2.adaptiveThreshold( img_blur, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, tt, bs, c ) # 简单的评分：计算白色区域的连通域数量 # 连通域越少，说明目标越完整，噪点越少 num_labels, _ = cv2.connectedComponents(binary) score = -num_labels # 连通域越少分数越高 if score > best_score: best_score = score best_params = (bs, c) print(f"推荐参数: blockSize={best_params[0]}, C={best_params[1]}, thresholdType={'BINARY' if tt == cv2.THRESH_BINARY else 'BINARY_INV'}") return best_params # 使用示例 # 假设目标是暗色字符，后续需要白色前景 adaptive_threshold_tune('part.png', target_is_bright=False, target_should_be_white=True)

这个模板的核心逻辑是：先根据“目标亮度”和“期望输出极性”自动决定thresholdType，然后在一个合理的参数范围内搜索最优的blockSize和C。评分函数用的是连通域数量，这个指标在大多数场景下都能反映二值化的质量——连通域越少，说明目标越完整，背景越干净。

当然，这个评分函数不是万能的。对于某些场景，比如目标本身就是多个分散的小点，连通域数量多反而是正常的。这时候需要根据具体任务调整评分逻辑。但作为一个起点，这个模板能帮你快速排除掉明显错误的参数组合，把精力集中在少数几个候选上。

9. 关于“调错边”的最终建议

回到标题那句话。自适应阈值调了三年，可能一直在调错那一边。这个“边”指的就是THRESH_BINARY和THRESH_BINARY_INV之间的选择。它看起来只是黑白颠倒，但在整个图像处理流水线里，它决定了后续所有步骤的输入极性。

我的建议很简单：下次你写adaptiveThreshold的时候，先停下来30秒，做三件事。

第一，看一眼原图，确认你的目标区域是亮的还是暗的。

第二，想一下后续算法需要目标区域是白色还是黑色。

第三，根据前两个答案，决定用THRESH_BINARY还是THRESH_BINARY_INV。

这三步花不了半分钟，但能帮你省下几个小时的无效调参时间。我自己的项目里，这个习惯已经变成了条件反射。每次写二值化代码，手会先停在thresholdType那个参数上，脑子里过一遍极性关系，然后再往下写。

至于blockSize和C，它们当然重要，但它们是在极性选对之后才有意义。极性错了，这两个参数调得再精细，也只是在错误的道路上越走越远。先把“边”选对，再调“阈值”，这个顺序不能反。