日志监控问题：可有办法将请求的调用源码地址包括代码行数也上报上去？【热度: 814】

[yanlele]

关键词：日志监控问题

在使用了代码混淆（例如 Webpack 的 mina-hash、chunkhash 或 contenthash）的前端代码中，即使执行了混淆，依然可以通过以下方法在日志监控时提供足够的上下文信息，主要包括被请求的源代码地址以及代码行数：

源码映射(Source Maps)

1. 生成 Source Maps:
   在构建过程中生成功能强大的源码映射（Source Maps）文件是标准做法。Source Maps 主要用于将混淆、压缩后的 JavaScript 代码映射回到其原始版本，允许在浏览器调试工具中查看原始代码和追踪错误。

   • 保存映射文件: 在生产版本中生成如.map的 Source Map 文件，并确保它们正常处理（通常是将它们放置在服务器上的一个公开但安全的位置）。
   • 反映在 Source Maps 中的映射: Source Maps 文件应将原始的源文件路径和行号映射到构建后的代码中对应的位置。

2. 错误跟踪系统集成:
   使用错误跟踪工具（也常被称为 Error Monitoring 平台, 如 Sentry、LogRocket、Bugsnag 等），这些工具通常兼容并支持 Source Maps:

   • 自动和源码追踪:
     漏洞和崩溃报告将自动包含被未混淆的源码引用，您只需确保生产版本的 Source Maps 配置正确。

   • 代码行号报告:
     用户报告的堆栈跟踪信息将包括对应底层源文件，而非混淆后的行号。

自定义错误日志逻辑

1. 覆盖全局的错误处理器：
   对于更高级的错误追踪，你可能需要在前端代码中维护自定义的错误处理逻辑。

   • 使用.Window.onerror或try...catch:
     在Window.onerror中捕捉到运行时错误时，或者在自定义函数内try...catch捕获的错误，你可以从错误的堆栈跟踪中提取当前运行代码的位置，并尝试将符号化的堆栈信息发送到后端服务器。

2. 在后端查阅符号化堆栈:
   为了安全和性能的考虑，源码映射通常不包括在客户端的部署中。因此固体堆栈信息需要在服务器端符号化，这是针对转换后的堆栈轨迹进行处理，将反向转换为源代码行。

注意:

• 确保 Source Maps 不公开到客户端以避免潜在的安全风险。应该将它们存放于受控的服务器环境，以避免源码泄露或不当使用。
• 以上方案更适合于开发或测试环境提供详细调试信息，确保在最终部署产品之前只公开给授权的人员。