行覆盖率不足源于测试未触达特定逻辑，需精准构造用例覆盖标红代码行，如参数校验、getter/setter副作用、默认值逻辑、异步分支及早期返回等场景，每次聚焦一行补漏。
行覆盖率不够，说明有些代码行根本没被执行到——不是测试写少了，而是测试没“触达”那些逻辑。关键不是堆用例，而是让每个新增测试精准点亮一行或多行未覆盖的代码。
从报告里揪出真正没跑的行
运行 npx jest --coverage 后打开 coverage/lcov-report/index.html，直接点进低覆盖率文件，找标红的行（尤其是带条件、赋值、return、throw 的地方）：
-
构造函数里的参数校验语句：比如
if (typeof precision !== 'number') throw new Error()，若只传数字，这行永远不亮；补一个非数字输入即可 -
getter/setter 中的计算或副作用：如
set name(val) { this._name = val?.trim() || ''; }，需分别测null、空格字符串、正常字符串 -
默认值兜底逻辑：像
const timeout = options.timeout ?? 5000;，得传{}或{ timeout: undefined }才能触发??右侧
按函数类型补漏，不笼统“测这个方法”
同一函数不同位置的未覆盖行，往往对应不同职责，要分类击破：
-
纯计算函数（如
formatPrice(n)）：补NaN、Infinity、负数、超大数，尤其注意浮点运算后是否用了toFixed或Math.round—— 那些四舍五入分支常被跳过 -
带副作用的函数（如
saveToStorage(data)）：mocklocalStorage.setItem，再传合法/非法data，确保写入语句和错误处理语句都被执行 -
状态判断函数（如
canSubmit()）：它内部可能有return this.isValid && this.isDirty && !this.isSubmitting;，需分别设三组状态使整个表达式为true、false（任一为假），才能点亮所有中间逻辑行
警惕“看似执行了，实则跳过”的假象
有些行在调试器里看着走了，但覆盖率不亮，常见于：
-
异步代码没等完：函数声明没加
async，或await调用被遗漏，导致then回调或await后续行完全没执行 -
mock 掩盖了分支：比如 mock 了
fetch返回成功，但实际函数里还有if (!res.ok) throw ...，这行永远不会跑 —— 得补一个 mock reject 的用例 -
早期返回（early return）拦截了后续行：例如函数开头
if (!user) return null;，后面所有行都依赖user存在；那就必须先写一个user = null的用例，再写一个user = {...}的用例
每次只攻一点，见效快且不返工
别想一口吃成胖子。打开报告，挑最刺眼的一行红（比如某 console.error 日志、某个 throw、某条 else 分支里的赋值），就为它写一个最小输入：
- 报告说第 42 行
throw new ValidationError('email');没亮 → 传一个无 email 字段的对象进去 - 第 67 行
return data.items.map(...);没执行 → 确保data.items是数组（而非undefined或null） - 某
for循环体内的行全黑 → 先试空数组（循环不进），再试单元素数组（只进一次）
