Angular需unsafe-eval的ngx-translate-messageformat-compiler替代方案

核心背景 #

原有使用的ngx-translate-messageformat-compiler因为底层编译逻辑依赖动态eval生成格式化函数，强制要求CSP的script-src配置开放'unsafe-eval'权限，会带来不必要的安全合规风险，以下是经过生产验证的可落地替代路径。

具体可选方案 #

• 最低成本迁移方案：基于formatjs intl-messageformat实现ngx-translate兼容编译器
  你之前调研的formatjs intl-messageformat本身是完全框架无关的纯JS库，从v3版本开始已经彻底移除了eval依赖，所有ICU消息格式的解析、复数处理、嵌套规则匹配都是纯字符串逻辑实现，完全满足严格CSP要求，不需要开放'unsafe-eval'。
  这个库之所以没有官方的Angular适配文档，是因为它的定位是底层格式化引擎，本身没有绑定任何前端框架，只需要实现ngx-translate要求的编译器接口即可完成适配：整个适配层只需要实现一个标准的compile方法，方法内部直接初始化IntlMessageFormat实例、传入当前语言和参数完成格式化即可，社区已经有成熟的开源实现可以直接使用，不需要从零开发。
• 新项目低依赖方案：脱离ngx-translate生态，直接使用intl-messageformat结合Angular依赖注入做封装
  如果项目没有历史ngx-translate的存量代码包袱，可以直接把intl-messageformat作为翻译能力的核心，通过Angular的依赖注入把当前激活的语言上下文、已加载的翻译字典注入到格式化服务中，还能更好的做Tree-Shaking优化，只打包项目实际用到的语言规则和格式化能力，控制整体包体积。
• 长期升级方案：对接Angular原生i18n能力
  对于已经升级到Angular 14及以上版本的项目，可以逐步把存量翻译逻辑迁移到Angular官方的@angular/localize原生i18n体系上，结合intl-messageformat做消息格式的校验和预处理，整个链路全程无动态eval，从根源上满足最严格的CSP要求。

常见认知澄清 #

很多开发者误以为intl-messageformat也需要依赖eval能力，实际上从大版本v3开始，formatjs团队已经把原本基于eval的动态代码生成逻辑完全替换为纯状态机解析实现，是目前公开的ICU消息格式化方案中CSP合规性最好的选项。

迁移注意事项 #

• 选择第三方适配包的时候要确认依赖的intl-messageformat版本在v3以上，避免用到还保留eval逻辑的老版本实现
• 适配层需要对已经编译过的消息做内存缓存，避免每次翻译调用都重复解析ICU字符串，带来不必要的性能损耗
• 配置CSP的时候可以把script-src的权限完全收紧，不需要为了翻译能力额外开放动态脚本执行权限

内容的提问来源于stack exchange，提问作者Sarah Mandana