在新项目中如何把「allowJs」写得更稳？：团队代码评审中的问题总结
很多团队在引入 allowJs 时，只关注能否快速让 JavaScript 和 TypeScript 混合开发，却容易忽略现有构建链、类型检查范围和历史代码质量对项目稳定性的影响。新项目一开始就开启 allowJs，通常会带来哪些需要提前评估的风险点？
需要重点关注构建、类型与规范三类风险
在新项目中启用 allowJs 时，最常见的风险来自三方面：构建工具是否支持混合文件输入，TypeScript 是否会对 JS 文件产生预期内的检查结果，以及团队是否已经统一了 JS 和 TS 的编码规范。若路径别名、模块解析、Babel 或打包器配置没有同步调整，项目很容易出现能编译但运行异常的情况。另一个常见问题是类型边界不清晰，导致 JS 文件长期处于“可用但不可控”的状态。建议在启用前明确目录边界、检查规则和迁移节奏，让 allowJs 只承担过渡或兼容角色，而不是成为长期混杂的默认方案。
有些项目配置看起来没有问题，但在代码评审阶段仍然会暴露出很多隐患，比如 JS 文件越来越多、类型提示失真、公共模块被错误复用等。站在评审视角，哪些代码信号能帮助判断 allowJs 是否正在把项目带向更难维护的方向？
可以从文件分布、类型边界和调用方式判断
评审 allowJs 时，可以重点观察三个信号。第一，JS 文件是否在核心业务层持续扩张，如果核心模块越来越依赖 JS，说明类型治理已经偏弱。第二，TS 文件是否频繁对 JS 输出进行大量断言或兜底处理，这通常意味着类型信息没有被有效沉淀。第三，公共工具、API 层或状态管理层是否被 JS 直接引用且缺少明确声明，这会让依赖关系变得模糊。若这些信号持续出现，allowJs 就不再只是过渡方案，而是在放大维护成本。评审时应推动模块分层、收敛 JS 使用范围，并为关键接口补足类型定义。
有些团队在新项目启动时就默认开启 allowJs，也有团队会等代码规模上来后再考虑兼容 JavaScript。对于一个协作人数不算少的新项目来说，allowJs 更适合用于哪些阶段，怎样用才不容易影响整体开发效率？
更适合迁移期、整合期和临时兼容场景
allowJs 更适合用于迁移期、整合期或临时兼容场景，而不是作为新项目的长期默认开发模式。迁移期指的是团队已经有存量 JavaScript 代码，需要逐步转向 TypeScript；整合期则是某些外部依赖、工具脚本或历史模块暂时无法全部改写；临时兼容场景则适用于少量边界代码需要快速接入项目。若新项目从一开始就大规模使用 allowJs，团队很容易在命名、类型、测试和审查标准上产生分歧。更稳妥的做法是把 JS 限定在少数目录中，并配合严格的 lint、测试和类型声明策略，避免混合开发失控。
项目在初期可能看不出问题，但随着模块增多，allowJs 带来的维护成本会逐渐显现。作为开发者或评审者，应该通过哪些现象判断它已经开始影响代码质量，而不是仅仅停留在“能跑就行”的阶段？
看类型回退、重复逻辑和变更成本是否上升
当 allowJs 开始影响可维护性时，通常会出现三个现象。其一，类型回退变多，开发者为了通过检查而大量使用 any、断言或忽略错误。其二，重复逻辑增加，因为 JS 和 TS 模块之间边界不清，团队倾向于复制代码来规避引用复杂度。其三，变更成本上升，一个小改动需要同时检查多个文件类型、构建结果和运行行为。若这些问题持续出现，说明 allowJs 已经从“兼容方案”演变成“维护负担”。此时应收紧使用范围，明确哪些目录允许 JS，哪些模块必须使用 TS，并把类型质量纳入评审标准。