babel仅做语法转换，不校验正确性；eslint和运行时检查才负责捕获未定义变量、api兼容性、插件配置错误等问题，ci中必须在babel后插入这三类校验并阻断失败流程。
Babel 本身不负责校验产物正确性，它只做语法转换；真正需要在校验环节介入的是 ESLint 和运行时/构建后检查工具。CI 中不能只信任 Babel 编译成功就认为输出安全——编译通过 ≠ 代码可执行、兼容、无逻辑隐患。
为什么 Babel 的成功编译不能代表产物正确
Babel 是转译器，不是验证器。它只确保输入 JS 能被解析成 AST 并按规则生成目标代码，但不管：
- 是否引入了未声明的全局变量（如 window.foo 在严格模式下报错）
- 是否用了目标环境不支持的 API（如 Array.prototype.flatMap 未被 polyfill 覆盖）
- 是否因插件配置错误导致关键语法未转换（如漏配 @babel/plugin-transform-classes，导致 class 保留原样）
- 是否因 targets 配置过宽（如写成 {"chrome": "100"}），本地开发能跑，CI 构建机 Node 版本低却静默失败
CI 中真正该做的三类校验动作
必须在 Babel 执行之后、部署之前插入以下检查，且全部失败需阻断流水线：
- ESLint 检查编译后代码：用 eslint --ext .js,.mjs dist/ 扫描产出目录（非 src）。启用 no-undef、no-restricted-globals 等规则，捕获未定义引用；配合 eslint-plugin-node 校验 Node 兼容性
- 运行时最小化执行验证：用 node --check dist/index.js 或 node -c dist/bundle.js 做语法预检（不执行，仅解析）；对入口文件做轻量 require（如 node -e "require('./dist/index.js')"）确认模块可加载
- 产物结构与内容断言：写简单脚本检查 dist/ 下是否存在预期文件、是否含 use strict、是否不含 console.log / debugger（用 grep -r 或 jq 配合 cat dist/*.js | grep -q "console\.log"）
避免常见陷阱的实操要点
很多团队把 ESLint 放在 src 上 lint 就以为万事大吉，这是错的：
- ESLint 规则必须和 Babel 输出对齐：比如开了 @babel/preset-env + core-js，ESLint 就不该报 Promise 不支持；否则 CI 会因规则冲突反复失败
- 不要跳过 .mjs 或 type: "module" 文件——Babel 默认不处理它们，需显式配置 extensions: [".js", ".mjs"]
- 若使用 Vite 或 SWC 替代 Babel，校验逻辑不变，只是检查对象从 dist/ 变为 .vite/deps/ 或 build/，路径要同步更新
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
