函数覆盖率低主因是关键路径未触发，需聚焦导出主函数、低分支覆盖率函数及多调用/副作用函数，通过边界输入、失败路径、状态组合补测，并改造耦合代码以提升可测性，最后将阈值和测试要求纳入CI与PR流程。
函数覆盖率低，往往不是测试写得少，而是关键路径没被触发——比如条件分支没走、错误流程没模拟、边界输入没覆盖。补测不靠堆数量，而要精准打在“代码动了但测试没跟上”的地方。
盯住三类易漏的执行路径
打开覆盖率报告（如Vitest或Jest生成的HTML），按“Functions”或“Branches”排序，优先补测以下三类函数：
- 导出的业务主函数（如
submitOrder、parseConfig），它们常含多层判断和副作用 - 含
if/else、switch、try/catch且分支覆盖率低于60%的函数 - 被多个模块调用、修改全局状态、或发起网络请求的函数（即使行覆盖高，异常分支可能完全没跑）
补测不是全覆盖，而是打穿关键分支
对每个目标函数，只补测真正影响行为的分支，不用追求100%语句覆盖：
-
边界输入：传
null、undefined、空数组、NaN、负数、超长字符串——尤其校验、索引、解构类逻辑 -
失败路径：用
vi.mock()让依赖返回Promise.reject()、HTTP 401/500、或抛出错误，验证catch块是否执行、错误提示是否正确 -
状态组合分支：例如
if (user.loggedIn && !user.hasTrial)，需准备三组数据分别触发true、false、false（即loggedIn=false或hasTrial=true）
让老代码“能被测”，再补用例
如果函数本身耦合全局变量、硬编码配置、或嵌套过深，直接写测试会卡住。先做最小改造：
- 把大函数中独立逻辑块（如错误处理、数据清洗）抽成小函数，单独导出并测试
- 将
window.API_BASE、global.config等全局读取，改为参数传入或依赖注入，测试时可自由替换 - 把
if (env === 'prod') {...} else if (env === 'test') {...}换成策略对象{ prod: handlerA, test: handlerB }，再分别覆盖handlerA和handlerB
补完就进CI，避免下次又漏
补测不是一次性动作。把它固化为开发流程的一部分：
- 在
jest.config.js或vitest.config.ts中，为已识别的核心文件设分支覆盖率阈值，例如：coverageThreshold: { './src/utils/validator.js': { branches: 90 } } - PR模板里加一条要求：“本次修改涉及哪些判断分支？请列出对应测试用例名（如
should throw when input is null）” - 用
vi.useFakeTimers()配合vi.runAllTimers()或await waitFor()，确保定时器、节流、防抖类逻辑也能被触发和断言
