上周的时候，远程调试一个 golang 的项目，因为要传入一些参数的原因，被逼着要用 launch.json 了，好在集成环境已经进化到可以自动生成一个模板了，大概长这样。

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch",
            "type": "go",
            "request": "launch",
            "mode": "auto",
            "program": "${fileDirname}",
            "env": {},
            "args": []
        }
    ]
}

环境的智能化是有几个坑的。对于 go 的项目，尽管都是 launch 请求，然鹅，当你对 program 指定不一样的内容时，其实质是不同的，但在开着 main.go（或者等价的主源文件）进行调试时尤其容易产生作用相同的错觉。

如果 program 里指定为 ${fileDirname}，那就是调试当前打开的源文件，而如果指定为 ${workspaceFolder} 的话，那就是调试当前的项目。vscode 会把要调试的可执行文件自动编译为 __debug_bin 的文件名，截至本文，老夫尚且不知如何才能指定一个自己想要的文件名，而且，如果写一个不允许改变可执行文件名、在执行时会进行检查的程序的话，那调试还得想辙儿。

还有一个坑是偷懒时踏进去的，在 args 里。当将其指定为 ["-c /svc/sdaemon/sd.conf"] 后，发现程序执行的行为不正常，能够感知到要指定配置文件，但却找不到配置文件。调试后得知，在寻找配置文件的时候，代码会试图打开 /svc/sdaemon/sd.conf 而不是 /svc/sdaemon/sd.conf（注意前面多了一个空格）。原本简直就要上手修改命令行解析器的我，在斥责其实现竟然如此幼稚脆弱的惊愕之余，幸而想到把 args 参数改为 ["-c", "/svc/sdaemon/sd.conf"] 一试，果然河清海晏。