VSCode自身日志由--log参数控制，Java应用日志需通过launch.json的vmArgs配置JVM参数，SSH远程日志则依赖settings.json中remote.ssh.logLevel设置，三者互不替代；且须确保日志依赖存在、配置文件路径正确、VSCode重启生效。
直接用 --log 启动参数控制 VSCode 自身日志级别
VSCode 主进程、渲染进程和扩展的日志输出，不依赖插件配置，而是由启动时的 --log 参数决定。没加这个参数，默认只记录极少量错误，vscode-logs/ 目录压根不会生成。
常见有效值只有 trace、debug、info、warn、error，其中：
-
trace输出最全：含 IPC 消息、事件循环耗时、模块加载顺序，适合排查 Extension Host 卡死或启动慢 -
debug是平衡选择：覆盖大部分插件通信与语言服务器交互，日常调试够用 -
info及以上基本看不到扩展行为细节，仅建议用于快速验证主进程是否异常
执行示例（macOS/Linux）：code --log=debug /path/to/project
Windows 命令提示符下：code.exe --log=trace C:\myapp
launch.json 里的 vmArgs 控制 Java 应用日志级别
VSCode 调试 Java 时，--log 管的是编辑器自身，不是你的程序。要改 Java 进程的日志输出，必须通过 launch.json 的 vmArgs 传 JVM 参数。
关键点：
- Spring Boot 项目用
-Dlogging.level.root=DEBUG，不是log4j.rootLogger=DEBUG - Log4j2 项目需额外指定配置文件路径：
-Dlog4j.configurationFile=src/main/resources/log4j2.xml - 中文乱码？补上
-Dfile.encoding=UTF-8，否则日志里一堆 - 多个参数要写成数组形式，不能拼成单个字符串
正确写法示例：
{
"configurations": [
{
"type": "java",
"name": "Debug",
"request": "launch",
"mainClass": "com.example.App",
"vmArgs": [
"-Dlogging.level.root=DEBUG",
"-Dfile.encoding=UTF-8"
]
}
]
}
远程开发场景下，settings.json 中的 remote.ssh.logLevel
当你通过 SSH 连进 Linux 服务器调试时，VSCode 客户端和服务端之间的连接日志，得靠 settings.json 配置，--log 在本地启动时无效。
设置位置：VSCode 设置界面搜 remote.ssh.logLevel，或直接编辑用户 settings.json：
-
"remote.ssh.logLevel": "debug"→ 记录 SSH 连接、密钥认证、端口转发失败原因 -
"remote.wsl.debug": true→ WSL 场景下启用 WSL 启动日志（仅 Windows） - 这些日志不会写入文件，统一输出到 VSCode 底部面板的 “输出” → “Remote - SSH” 标签页
注意：该配置对 Java 应用本身日志无影响，它只管“怎么连上去”，不管“连上去后跑什么”。
容易被忽略的三个硬性前提
无论用哪种方式改日志级别，以下三点任一缺失都会导致“设了等于没设”：
- Java 项目缺日志实现依赖：有
slf4j-api没log4j-core或logback-classic，vmArgs再全也白搭 -
log4j2.xml或logback.xml不在src/main/resources下，JVM 根本找不到配置文件 - VSCode 没重启：修改
settings.json或launch.json后，已打开的调试会话不会自动重载参数，必须关掉再启
日志级别是开关，但依赖、路径、重启才是让开关真正起作用的物理通路。漏掉任何一个，就只能看到空荡荡的控制台。
