jvm规范仅支持每个方法绑定单一源文件，无法为方法内不同代码段指定不同源文件；虽可通过sourcedebugextension属性扩展调试信息，但主流工具（如异常栈追踪）并不支持该特性。
在基于ASM编写JVM后端编译器时，为提升调试体验，开发者常希望在生成的字节码中嵌入精确的源码位置信息——尤其是当启用跨模块内联等全程序优化后，一个方法体可能融合来自多个源文件的逻辑片段。遗憾的是，JVM的原生调试信息模型存在根本性限制：LineNumberTable 属性仅支持将整段字节码指令序列映射到单一源文件中的行号，而 SourceFile 属性本身也仅允许类级别声明一个源文件名（通过 ClassVisitor.visitSource(source, debug) 设置）。
这意味着：即使你通过 MethodVisitor.visitLineNumber(line, label) 为不同指令标注了不同行号，这些行号仍被默认关联到 visitSource 所指定的同一个源文件。JVM运行时（包括异常栈打印、Throwable.getStackTraceElement()）严格遵循此约定，不支持按指令粒度切换源文件。这一设计已被OpenJDK明确拒绝改进——JDK-4972961 提案曾建议增强多源文件支持，但最终标记为 “Won’t Fix”。
使用 idealista CLI 按位置（城市、城镇、地区、街道）搜索 Idealista 房源并获取详情。适用于用户请求 Idealista 市场数据或需要 idealista‑cli 命令/标志时。
不过，JVM规范确实预留了扩展机制：SourceDebugExtension 属性（见 JVMS §4.7.11）。它允许在类级别附加任意格式的调试元数据。ASM中可通过 visitSource(null, "your-debug-extension-data") 将自定义内容写入该属性。例如：
// 示例：向类添加SourceDebugExtension（需自行定义格式）
classWriter.visitSource(null,
"SMAP\n" +
"Generated.java\n" +
"Java\n" +
"*S Java\n" +
"*C Generated.java\n" +
"*L\n" +
"1#1,10:OriginalA.java|20\n" + // 指令范围1–10 → OriginalA.java 第20行起
"11#1,15:OriginalB.java|5\n" + // 指令范围11–15 → OriginalB.java 第5行起
"*E\n"
);⚠️ 关键注意事项：
- 此属性不被JVM运行时解析，printStackTrace() 和标准调试器（如JDB、IDEA默认模式）完全忽略它；
- 仅少数专业调试工具（如某些LLDB插件、定制化IDE调试器）可能解析并利用该数据；
- 规范未定义其内容格式，实际采用需参考DSOL 1.0规范或目标工具文档；
- 过度依赖该机制可能导致调试体验碎片化，降低可维护性。
总结建议：
在投入精力实现 SourceDebugExtension 前，请务必验证目标开发环境（如IntelliJ、VS Code Java Extension、特定CI调试工具）是否真实支持该属性及其约定格式。更务实的策略是：
- 优先保证 LineNumberTable + 单一 SourceFile 的基础调试可用性；
- 对高度内联的关键方法，生成带注释的伪源码（如GeneratedWithInlines.java），并在注释中标明原始出处；
- 结合构建时生成映射报告（如JSON格式的指令→源文件/行号对照表），供高级调试场景按需查询。
毕竟，调试信息的价值取决于工具链的支持程度，而非字节码层面的理论可能性。
