直接回答:减少JS/TS运行时错误的关键不是“让AI更谨慎”,而是把外部数据、可空值、配置和异常变成机器可检查的约束。TypeScript严格模式、运行时验证和测试结合,能让很多问题在上线前暴露。[1][2]

运行时错误要尽量前移到类型和测试阶段
TypeScript开启strict会启用一组更严格的类型检查;strictNullChecks能把null/undefined从“默认忽略”变成需要显式处理的类型问题。[1][2]
让AI优先修“边界类型”
- API响应不要直接as成目标类型;
- 外部JSON在进入核心代码前验证;
- DOM查询、Map.get、find等可能返回空值的位置显式处理;
- 环境变量统一集中读取和校验;
- 错误对象先缩窄类型再访问属性。
{
"compilerOptions": {
"strict": true,
"noUncheckedIndexedAccess": true
}
}JavaScript项目也能逐步加防线
不必一次把大型JS项目全部迁成TS。可以先对高风险模块增加JSDoc/检查、测试和运行时Schema验证,再逐步迁移。AI适合批量补类型候选,但公共类型和外部接口应人工审查。
| 错误来源 | 防线 |
|---|---|
| null/undefined | strictNullChecks + 显式分支 |
| 接口字段变化 | 运行时Schema验证 + 类型生成 |
| 对象键不存在 | 索引访问检查 |
| 异步异常 | 统一错误边界和日志 |
| 环境差异 | 配置Schema + 启动时校验 |
不要用any把问题“修绿”
当AI遇到类型报错时,最容易使用any、非空断言或类型强转快速消除红线。提示词里应明确:禁止扩大any、禁止无证据的!和as unknown as,需要解释为什么类型可以被缩窄。
参考来源
- TypeScript:strict(核验于 2026-08-08)
- TypeScript:strictNullChecks(核验于 2026-08-08)
- TypeScript:Compiler Options(核验于 2026-08-08)
更新记录
- 2026-08-08:核验官方资料并完成全文结构化撰写。
© 版权声明
文章版权归作者所有,未经允许请勿转载。