附加调试前必须确认目标进程已启用调试支持，如Node.js需--inspect、.NET需带PDB且未禁用调试、Python需debugpy.listen()；launch.json中attach配置须按语言正确设置端口、地址等参数；断点不命中常因路径映射或符号未加载；多进程需显式配置子进程调试。
附加调试前必须确认进程已启用调试支持
VSCode 本身不能凭空附加到任意进程——目标进程得自己“准备好被调试”。比如 Node.js 进程必须以 --inspect 或 --inspect-brk 启动，否则 vscode-js-debug 扩展会连不上；.NET 应用需编译带符号（.pdb 文件），且运行时未禁用调试（如没加 COMPLUS_Logging=0）；Python 的 debugpy 则要求目标进程已执行 debugpy.listen() 并处于等待连接状态。
常见错误现象：Could not connect to debug target、No debug adapter available、列表里根本看不到目标进程。别急着查 VSCode 设置，先用命令行确认：
- Node.js：运行
ps aux | grep -- --inspect或检查启动命令是否含--inspect=9229 - .NET：用
dotnet-dump ps（需安装dotnet-dump工具）看进程是否在运行中且有调试端口监听 - Python：检查目标脚本里是否有
import debugpy; debugpy.listen(5678)，且未被注释或跳过
launch.json 中 attach 配置的关键字段不能照抄模板
VSCode 调试依赖 .vscode/launch.json 里的 type、request 和具体适配器参数。不同语言的 attach 模式字段差异很大，硬套 Node.js 的配置去连 Python 进程只会报错。
实操建议：
- Node.js：必须指定
"port": 9229（或你启动时设的端口），"address": "localhost"一般不用改；若进程在 Docker 容器里，"address"得填容器 IP 或用"address": "host.docker.internal"（macOS/Windows） - Python：用
"type": "python"时，"request": "attach"下必须有"connect": { "host": "localhost", "port": 5678 }，且确保debugpy版本与 VSCode Python 扩展兼容（例如debugpy <=1.6不支持 Python 3.12+） - .NET：选
"type": "coreclr"，"processId"可留空让 VSCode 弹出进程选择框，但若填了就得是真实 PID（用ps -ef | grep dotnet查），填错直接提示Process with specified id does not exist
附加后断点不命中？先检查源码路径映射和符号加载
附加成功 ≠ 断点能停。最常被忽略的是路径不一致：你在 VSCode 里打开的是 /Users/me/project/src，但进程加载的模块实际来自 /app/src（如 Docker 挂载路径不同），断点就永远灰色。
解决方式取决于语言：
- Node.js：
launch.json加"sourceMaps": true，并确认生成了.map文件；若用了 webpack/vite，检查devtool是否为source-map或inline-source-map - .NET：确保
.dll同目录有对应.pdb，且 VSCode 的"justMyCode": false（如果想进框架代码）；Linux 上注意大小写敏感，MyApp.dll和myapp.dll是两个文件 - Python：
debugpy默认不支持远程路径映射，得靠"pathMappings"手动配，例如{"<code>/app": "${workspaceFolder}"} —— 这个字段只在attach模式下生效，launch模式不认
多线程/多进程场景下容易漏掉子进程
VSCode 默认只附加到主进程。如果你调试的是一个 fork 出子进程的 Node.js 服务，或 Python 用了 multiprocessing，主进程断点能停，子进程完全不受控。
应对策略：
- Node.js：启用
"autoAttachChildProcesses": true（仅限js-debug扩展），但注意这会增加启动开销，生产环境勿开 - Python：
debugpy本身不自动 attach 子进程，得在子进程启动逻辑里显式调用debugpy.listen()并换端口（如 5679），再单独配一个attach配置连过去 - .NET：CoreCLR 调试器支持
"subProcess": true（需 .NET 6+），但仅对Process.Start创建的子进程有效，对fork类型的 Unix 子进程无效
附加调试不是“点一下就完事”的操作，进程状态、符号路径、网络可达性、子进程生命周期——每个环节断掉，都会让你卡在“连上了但没完全连上”的状态。尤其当目标跑在容器或远端服务器时，本地 localhost 和容器内 127.0.0.1 根本不是一回事，得一层层验证端口、防火墙、挂载路径和调试器版本兼容性。
