断点不触发主因是vscode未真正attach到运行时上下文：需确保launch.json中program指向同步初始化入口、sourcemap覆盖所有分片配置文件、多实例场景改用attach模式并启用autoattachchildprocesses，避免动态加载导致映射断裂。
断点打在 DataSource 初始化或 getRepository 调用处没反应？大概率不是 TypeORM 本身的问题，而是 VSCode 没真正 attach 到运行时上下文——尤其当多个 DataSource 实例并行初始化、或分片逻辑依赖异步加载时，调试器常因 source map 链路断裂或进程未正确挂载而“失联”。
launch.json 必须显式声明多实例启动模式
TypeORM 多数据源通常靠多个 DataSource 实例实现，但 VSCode 默认只监听一个入口。若你用 Promise.all([ds1.initialize(), ds2.initialize()]) 启动，调试器可能只捕获第一个实例的初始化栈。
-
request: "launch"时，program必须指向一个**同步触发全部 DataSource 初始化的入口文件**（比如src/bootstrap.ts），不能是仅导出配置但不执行.initialize()的文件 - 若分片配置从远程加载（如 HTTP 请求 +
await），需在launch.json中加"skipFiles": ["<node_internals>/**"]</node_internals>，否则调试器会在fetch内部卡住，跳过你的实际初始化逻辑 - 避免用
ts-node直接运行带import动态路径的文件——TypeScript 编译器可能提前解析失败，导致DataSource构造函数根本没执行；改用tsc编译后调试dist/bootstrap.js更稳
sourceMap 映射必须覆盖所有分片配置文件
TypeORM 分片常把连接配置拆到多个 .ts 文件（如 shard1.config.ts、shard2.config.ts），这些文件若未被 tsc 编译进 outFiles 范围，断点就会失效。
-
tsconfig.json中确保"sourceMap": true且"outDir"统一（如./dist），所有分片配置文件都放在src/config/**/*下，便于统一匹配 -
launch.json的"outFiles"不能只写["./dist/**/*.js"]，要显式包含配置目录：["./dist/**/*.js", "./dist/config/**/*.js"] - 若分片配置用了
require('./shard1.json')这类动态加载，JSON 文件本身无 source map，调试器无法映射——改用import shard1Config from './shard1.config.ts'并确保该文件参与编译
attach 模式更适合分片服务热重载场景
本地开发时，分片服务常配合 nodemon 或 ts-node-dev 热重载，此时 request: "launch" 容易因进程重启丢失调试会话。
- 改用
request: "attach"，并在package.json脚本中启动："debug": "ts-node-dev --inspect-brk --files src/bootstrap.ts" -
launch.json中配"port": 9229（与命令行一致），"address": "localhost"，并加"autoAttachChildProcesses": true——TypeORM 创建的子连接池进程才不会脱离调试上下文 - 注意
ts-node-dev的--inspect-brk会暂停在第一行，需在 VSCode 中按 F5 继续，否则DataSource根本不会初始化
最易忽略的是分片路由逻辑本身的执行时机：比如 @EntityRepository 或自定义 QueryRunner 分发器，它们常在请求到达后才决定用哪个 DataSource，这种延迟绑定的代码，断点必须打在实际调用链上（如 Controller 方法内），而不是配置文件里——后者只是静态定义，根本不参与运行时分片决策。
