Thi.ng/vectors 与 Content Security Policy 的安全实践

在现代前端开发中，安全性越来越受到重视，Content Security Policy (CSP) 作为一种重要的安全机制，能够有效防范 XSS 攻击。然而，当开发者使用 thi.ng/vectors 和 thi.ng/color 这样的高性能数学库时，可能会遇到 CSP 的限制问题。

问题背景

thi.ng/vectors 和 thi.ng/color 库为了提高性能，采用了动态代码生成技术，通过 compileHOF 函数和 new Function() 来创建优化的向量运算函数。这种技术在性能上带来了显著优势，但却与 CSP 的 unsafe-eval 限制产生了冲突。

技术挑战

CSP 的 script-src 'unsafe-eval' 指令虽然可以解决这个问题，但却会降低应用的整体安全性。开发者面临两难选择：要么牺牲安全性，要么放弃性能优化。

解决方案

thi.ng 团队经过深入研究，决定重构代码生成机制：

1. 静态代码生成：开发了专门的代码生成工具，将原本运行时生成的函数转为静态源代码
2. 文档字符串支持：借此机会为所有向量运算添加了完整的文档说明
3. 包结构优化：重新组织了代码结构，提升 tree shaking 效果

性能影响

重构后的包在体积和性能上表现出色：

• 完整包体积仅增加约1KB（brotli压缩后）
• 许多示例应用的包体积反而缩小了5-25%
• 启动时间得到改善，因为不再需要运行时生成代码

开发者建议

对于使用这些库的开发者：

1. 尽量使用细粒度导入，而非整体导入
2. 配合现代打包工具使用，充分利用 tree shaking
3. 注意检查是否有直接导入被重命名的函数

未来方向

虽然 vectors 和 color 包已解决 CSP 问题，但 thi.ng 生态中仍有部分库（如 pixel 和 shader-ast-js）必须使用动态代码生成。开发者在使用这些库时，仍需评估安全性与功能需求的平衡。

这次重构不仅解决了 CSP 兼容性问题，还提升了代码质量和开发者体验，展现了 thi.ng 团队对安全性和性能的双重追求。