dlz-lens — 你的代码运行透视镜
看透每一次调用。加一个依赖，就能看到你的应用和外部世界的每一次对话：SQL、Redis、HTTP、MQ…… 不是看日志，是看代码运行的回放。
- 业务线程开销：< 500ns（纳秒级，零性能负担）
- 接入成本：1 行配置开启，零业务代码侵入
- 支持类型：SQL · Redis · HTTP · MQ（持续扩展中）
- 核心能力：代码行级定位 · 请求故事回放 · 智能诊断 · IDE 一键跳转
它是什么
dlz-lens 是一个嵌入式的 IO 调用透视与故障诊断工具。
你只需要在项目中引入一个依赖，加一行配置，就能在浏览器里实时看到应用对外的每一次 IO 调用——SQL 查询、Redis 命令、HTTP 请求、MQ 消息……每一次调用都带着完整的上下文：谁调用的、参数是什么、花了多久、成功还是失败、在哪个请求里。
点击任意一次调用，直接跳转到 IDE 里对应的业务代码行。
它的定位是开发调试与故障诊断神器——不是 APM、不是监控大盘、不是日志搜索，而是让你在写代码、调 Bug、排故障的时候，能够一眼看透代码运行的完整路径。
为什么需要它
痛点 1：日志里找不到"是谁执行的"
线上报错了，日志里有 SQL 有异常，但你不知道这是哪行代码触发的。你得猜、得搜、得翻代码，半小时过去了还没定位到根因。
dlz-lens 解决：每一次调用都精准定位到业务代码行，点击直接跳 IDE。不是方法级，是行号级。
痛点 2：一次请求执行了啥？全靠猜
接口慢了，你不知道是某条 SQL 慢、还是 N+1 导致 SQL 太多、还是 Redis 慢、还是下游 HTTP 接口慢。没有完整的时间线，只能靠猜和经验。
dlz-lens 解决：按 TraceID 把一次请求的所有 IO 调用聚合成一个完整的"故事"，时间线一目了然。先查了什么、再改了什么、事务何时开始何时提交、哪步慢了、哪步错了——全部清清楚楚。
痛点 3：问题排查是个断点式的苦活
排障 = 查日志 → 猜 → 加日志 → 重跑 → 再查 → 再加日志……循环往复。
dlz-lens 解决：故障诊断完整闭环——从异常入口 → 关联 Trace → 看完整故事 → 定位问题调用 → 点回代码行 → 修复验证。一条链路走通，不需要反复加日志。
核心特性
🎯 代码行级定位（护城河）
跳过 Spring/MyBatis/Hikari/CGLIB 等所有框架栈帧，精准定位到你的业务代码行。点击调用栈任意帧，直接打开 IDEA 跳到对应行。
不是"方法级"，是行号级。不是"大概在这个类里"，是"第 42 行"。
📖 请求故事回放（护城河）
按 TraceID 聚合同一请求的所有 IO 调用（SQL / Redis / HTTP / MQ），时间线可视化重放完整执行路径。
不是一条条孤立的调用记录，是一个完整的执行故事。
🔍 智能诊断（护城河）
自动检测常见问题并标记：
- 慢调用：超过阈值的调用自动标记为慢
- N+1 问题：同 Trace 内重复调用模式检测，紫色标签醒目提示
- 事务风险：事务中包含 HTTP 调用、事务过大等风险自动检测
- 错误调用：执行失败的调用红色高亮，附完整异常信息
⚡ 实时监控
WebSocket 实时推送所有 IO 调用，Chrome DevTools 风格暗色主题，开发者熟悉的体验。
🔐 事务追踪
BEGIN / COMMIT / ROLLBACK 事务边界可视化，事务中的调用清晰可见。一眼看出事务范围是否合理。
🚀 极致性能
业务线程总开销 < 500ns，比一次 SQL 执行小 1000 倍。队列满直接丢弃，永远不阻塞业务线程。
支持的调用类型
| 类型 | 模块 | 状态 |
|---|---|---|
| SQL（JDBC） | dlz-lens-sql | ✅ 已支持 |
| MyBatis 增强 | dlz-lens-mybatis | ✅ 已支持（Mapper 定位） |
| Redis | dlz-lens-redis | 🔄 开发中 |
| HTTP（RestTemplate/WebClient） | dlz-lens-http | 🔄 规划中 |
| Feign | dlz-lens-feign | 🔄 规划中 |
| MQ（RocketMQ/Kafka） | dlz-lens-mq | 🔄 规划中 |
为什么不用 SkyWalking / ELK / Druid / P6Spy？
| 能力 | SkyWalking | ELK | Druid | P6Spy | dlz-lens |
|---|---|---|---|---|---|
| TraceID 串联 | ✅ | 要自己打 | ❌ | ❌ | ✅ |
| 精确到代码行 | ❌ 方法级 | ❌ | ❌ | ❌ | ✅ 行号+IDE跳转 |
| SQL 深度（参数/执行计划） | ❌ | 要自己打 | ⚠️ 部分 | ✅ 只有SQL | ✅ 结构化参数 |
| 自动诊断（N+1/事务风险） | ❌ | ❌ | ❌ | ❌ | ✅ |
| 一键跳 IDE | ❌ | ❌ | ❌ | ❌ | ✅ |
| 嵌入式零部署 | ❌ 要部署Agent | ❌ 要部署全套 | ✅ | ⚠️ 要配代理 | ✅ 一个jar |
| Redis/HTTP 同屏 | ⚠️ 要看配置 | ❌ | ❌ | ❌ | ✅ |
| 业务线程开销 | 中（微秒级） | 中（日志IO） | 中 | 高（格式化+写日志） | 极低（纳秒级） |
详细解读
vs SkyWalking：SkyWalking 是全链路 APM，功能全但很重，需要部署 Collector + Storage + UI 一整套，接入也复杂。而且它只能定位到方法级，做不到行号级，也没有 IDE 一键跳转。dlz-lens 是嵌入式轻量工具，加个依赖就能用，在"IO 调用调试"这个垂直领域做得更细更准。
vs ELK：ELK 是日志搜索平台，看到的是你打进去的日志文本。参数值、精确耗时、调用栈、事务上下文——这些在日志里要么没有，要么不全。dlz-lens 是在调用层直接拦截，拿到的是第一手结构化数据，信息完整度完全不在一个层面。
vs Druid：Druid 是连接池监控，做的是连接池管理和 SQL 统计。它能告诉你"哪条 SQL 执行了多少次、平均耗时多少"，但不能告诉你"这条 SQL 是哪行代码触发的、在哪个请求里、前面执行了什么"。
vs P6Spy：P6Spy 在业务线程上做 SQL 格式化、参数拼接、日志写入，开销较大（微秒级）。而且它只有 SQL 文本和参数，没有调用者定位、没有故事回放、没有 IDE 跳转、没有 Web UI。
适用场景
开发调试
写代码时实时看 IO 调用，参数对不对、语句对不对、有没有 N+1、事务边界对不对——一眼看清。
故障排查
线上报错了？找到对应 Trace，看完整故事，一眼定位根因。不需要反复加日志重跑。
性能优化
一个接口慢？看故事里的调用时间线——是某条 SQL 特别慢？是 N+1 太多？是 Redis 慢？还是下游 HTTP 慢？精准定位瓶颈。
Code Review
PR 提交前跑一遍，看看有没有意料之外的 SQL、隐式 N+1、不合理的事务范围。
新人上手
新同事不了解业务？跑几个请求看故事，秒懂代码流转路径。
性能承诺
业务线程总开销 < 500ns，比一次 SQL 执行小 1000 倍以上。
一条普通 SQL 执行要 0.5-1ms，我们增加的开销不到 0.1%。
怎么做到的？
- 业务线程只做最必要的事：栈快照捕获 + Caller 快速定位 + 非阻塞入队，完事
- 重活全在异步线程：栈帧对象创建、参数转换、存储分析、WebSocket 推送——全在消费线程做
- 队列满直接丢：
queue.offer()非阻塞，永远不阻塞业务 - 过载保护：队列 80% 时主动丢弃快调用，优先保留慢调用、错误、事务