断点打在装饰器上没反应，是因为装饰器（如@controller、@get）仅在类定义阶段执行并写入元数据，不参与运行时逻辑；真正需调试的是业务方法内部或nest元数据反射入口，而非装饰器声明行。
断点打在装饰器上没反应，是因为元数据根本没被读取
装饰器（比如 @Controller、@Get）本身只是语法糖，运行时是否生效，取决于 TypeScript 编译后是否保留元数据、Nest 是否在模块加载阶段主动读取。你在 main.ts 或控制器里打的断点，如果位于装饰器声明行（如 @Get()），VSCode 无法命中断点——因为那行代码不执行，只是被编译器处理成元数据写入 __metadata 对象。
真正该打断点的地方是 Nest 的元数据反射入口：比如 Reflect.getMetadata 调用处、或 ModuleRef 初始化逻辑。但更实际的做法是：在业务方法内部（如 users.service.ts 的 findAll()）设断点，确认请求进来后是否真走到这——如果没走到，问题大概率出在元数据未注册，而非断点位置不对。
- 确保
tsconfig.json中启用了"emitDecoratorMetadata": true和"experimentalDecorators": true - 检查
main.ts是否调用了NestFactory.create(AppModule)—— 如果漏掉AppModule，整个装饰器链就断了 -
AppModule的@Module({ controllers: [UsersController] })里必须显式列出控制器，不能只靠装饰器自动发现（Nest 不支持自动扫描）
调试依赖注入失败时，先看 ModuleRef.resolve() 是否返回 undefined
当 Injectable 类实例为 undefined，或构造函数参数报错 “Nest can't resolve dependencies”，不是代码写错了，而是模块树没正确构建。VSCode 里直接在 constructor 打断点意义不大，因为错误发生在 DI 容器初始化阶段，早于实例化。
有效做法是：在 node_modules/@nestjs/core/injector/module-ref.js 的 resolve 方法开头加断点（需开启“加载 node_modules 源码”选项），或在 main.ts 中 app.init() 后立刻调用 app.get(YourService, { strict: false }) 并设断点，观察返回值。
基于三引擎设计，从微信文章、新闻和博客网页提取干净内容，支持标题作者日期元数据，多格式和批量处理。
- 常见原因：提供者（
providers）没写进对应模块的@Module配置，或写了但用了错误的 token（比如用类名当字符串 token） - 全局提供者（
scope: Scope.TRANSIENT）在测试环境可能因缓存失效导致多次 resolve 返回不同实例，调试时注意清空jest缓存或重启进程 - 如果用了
useFactory提供者，确保工厂函数里没有异步逻辑（DI 容器初始化是同步的）
launch.json 用 attach 模式才能看到真实的装饰器执行上下文
用 request: "launch" 启动时，VSCode 自己拉起 Node 进程，但 Nest 的模块解析和元数据收集发生在 NestFactory.create() 内部，此时调试器还没完全 attach 上，部分装饰器钩子（如 @Inject 的反射时机）可能错过。
改用 request: "attach" 并配合 start:debug 脚本，能确保调试器全程监听——从 dist/main.js 加载第一行开始，所有 Reflect 调用、defineProperty 注入、甚至 RouterExplorer 解析路由的过程都可追踪。
- 脚本必须是
"start:debug": "node --inspect=0.0.0.0:9229 dist/main.js"，不能用ts-node，否则源映射错位，断点跳转到编译后 JS 而非 TS -
launch.json中outFiles必须包含"${workspaceFolder}/dist/**/*.js"，否则嵌套路径下的 controller/service 文件无法映射 - 启动后终端必须出现
Debugger listening on ws://127.0.0.1:9229/，没这行说明--inspect没生效
Node 版本低于 16.14 时，装饰器元数据在 Worker 线程里不可见
如果你在 @nestjs/bull 或自定义 WorkerThread 里使用 @Inject 或 @InjectQueue，Node.js Reflect.getMetadata is not a function。这不是 Nest 配置问题，而是 V8 的 worker_threads 模块在旧版本中未启用全局 Reflect API。
验证方式：在 Worker 内部加一行 console.log(typeof Reflect.getMetadata)，如果是 "undefined"，就得升级 Node 或改用主线程通信模式。
- Node 16.14+ 才默认开启
worker_threads的完整 ES 标准支持 - 即使升级 Node，也要确保
tsconfig.json中"target": "ES2020"或更高，否则 TypeScript 可能降级生成不兼容的代码 - 避免在 Worker 里直接 new Service 实例，优先用
process.send()+ 主线程代理调用
