应将 codemetrics.complexitythreshold 设为 6，因旋形复杂度超 6 时人脑难以即时理解分支路径，出错率上升、review 漏检概率翻倍；设为 10 失效，设为 3–4 误伤合法状态机；需在 settings.json 中正确配置并重载窗口。
默认值 10 没意义，真实项目里设成 6 才开始有用。 它不是“错误”，而是人脑短期记忆负荷超载的信号——函数复杂到这个程度，就该人工复查了。
为什么必须调低到 6？
旋形复杂度（Cyclomatic Complexity）超过 6，意味着分支路径组合已超出多数开发者即时理解能力。实测中：
- ≥6 的函数在大型项目中出错率明显上升，review 时漏掉逻辑分支的概率翻倍
- 设成 10 时，
codemetrics.complexityThreshold基本不亮红灯，等于关掉了告警 - 设成 3 或 4 会误伤合法状态机（比如带 5 个
else if的协议解析函数） - 长期卡在 7–9 的函数，大概率本该拆成两个职责清晰的函数，而不是硬撑
怎么改 settings.json 才生效
直接在 VSCode 用户或工作区 settings.json 里加这一行：
"codemetrics.complexityThreshold": 6
然后必须执行：Ctrl+Shift+P → 输入 Developer: Reload Window → 回车。不重载，状态栏不会变红，插件也不会重新扫描。
注意：
- 别写成
"complexityThreshold": 6—— 缺少命名空间前缀会失效 - 别用双引号包住数字，JSON 里数字不该加引号
- 如果同时装了多个度量插件（比如 CodeMetrics_VSCode 和 SonarLint），它们的阈值互不影响，得分别配
状态栏变红 ≠ 代码写错了
这是最关键的误解点。红标只表示「这段逻辑人脑难一次理清」，不是语法或运行时错误。它提示你：
- 该函数是否承担了太多职责（比如既做数据校验、又拼 SQL、还发 HTTP）
- 嵌套层级是否过深（
if套for套try） - 是否该提取为独立函数，哪怕只调用一次
真正难处理的是那些常年稳定在 7–8 的函数——没人动、没人敢动、测试覆盖又不全，它们才是技术债的温床。
