有人需要快速把 log 定位到代码上的工具吗？

sourcemap 是不是就是做这个的？

类似于 Sentry Java SDK 的东西么？

@julyclyde 不太一样，sourcemap 是让人看到代码真正的出错行数，这个工具是想把一很多行 log 对应的代码同时展示出来，方便跟着 log 理解代码是怎么走的。

@davin Sentry 应该是侧重解决错误，定位错误。 我的想法其实是更偏向于“理解系统运行时发生了什么”，就不管有没有错误，也可以通过 log 快速串联起代码执行路径，感觉更像是一个运行时代码路径追踪工具。

可能我和大家做的方向不太一样，我现在在搞鸿蒙系统开发，从 bsp 到 hal 再到 framework ，只要某个功能出了问题，就得跟全链路。

比如显示不正常，可能得从框架的图层状态，跟到渲染，合成，再到驱动，dts 。
再比如上层 app ANR 了，得从 app 跟到 framework service ，看看究竟系统出了什么问题。

做这个工具的初衷，是快速在眼花缭乱的 log 中，梳理出真正的代码执行流……而不是从每个模块的 readme 开始看起，这样太慢了……

这个东西做出来是很有用的，以前我也有过类似的想法，在 IDEA 导入 log 文件或者直连服务器定位到日志文件，然后可以根据线程号或者请求唯一 ID ，筛选日志来匹配代码，进一步的话可以根据 log 文件来模拟 IDEA 的 debug 。

不过我也只是想过，没啥实现思路。

@startisan 不谋而合！其实 log 本身就是精准的运行时，难点还是怎么根据用户意图筛选 log ，以及从 log 和代码中确定真正的执行流。实现基本就是人怎么根据 log 搜代码，程序就怎么搜。

单纯根据日志里面的堆栈信息定位，可以解决 99 的问题。 至于剩下的 1 ，要解决的话缺少的是需要一个带参数的日志回放系统，因为大部分难定位的问题都是循环套循环，同步转异步。这种情况下很难排查到底是什么情况下中断的异常。

@fulln 赞同，要排查这种问题确实很难，log 一般都不会为了调试打印全部参数，而且也不会随处打印，不像断点一样，能精确知道栈和内存。但是从最近用 AI Coding 的经验看，AI 貌似很会加 log ，数量多，而且关键参数信息也比较全。所以感觉日志回放可能是未来调试的大趋势。

C 基础库 CompilerServices 里面的 CallerFilePath CallerLineNumber CallerMemberName 参数特性
简直是 C 的 __FILE__ 和 __LINE__ 宏，把这些 log 起来就可以准确记录源代码位置
（这里不是 java 板块，我说 C 应该不算离题吧？

@coder001 哈哈哈当然不算，开头的图只是 gpt 生成的，其实我是搞 C 的。

C 能打出 file ，line 和 func name 我是知道的，不过你这个真神，居然能打印 caller 。属实涨见识了

其实我还想过编译器插桩，或者搞个 hook 统一打印所有函数的调用记录和参数。不过现阶段看起来没有必要，开销太大，而且有点麻烦，还得搞各种特殊版本。所以现阶段思路还是清洗 log ，RAG 代码然后分析出执行流。