vscode 的调试,最开始的时候,要手写 launch.json,当时嫌麻烦,没学习。搁了一阵子,发现变容易了,不管是 golang 还是 Python,找那个长得像播放键的按钮点就好了,通常会直接针对当前编辑区内的文件开始调试。
上周的时候,远程调试一个 golang 的项目,因为要传入一些参数的原因,被逼着要用 launch.json 了,好在集成环境已经进化到可以自动生成一个模板了,大概长这样。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
{ "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"]
一试,果然河清海晏。