唯一有效配置项是 workbench.fontsize，它控制资源管理器等所有侧边栏树形控件字体大小，值必须为整数且立即生效；window.zoomlevel 优先级更高，常掩盖其效果，需清空或设为 0 才能确保生效。
workbench.fontSize 是唯一有效配置项
VSCode 左侧资源管理器（文件树）的字体大小不响应 editor.fontSize，也不受主题或缩放干扰——它只认 workbench.fontSize。这个设置控制所有侧边栏树形控件：资源管理器、大纲、搜索结果、扩展列表，无法单独锁定“仅文件名”。
- 值必须是整数，如
"workbench.fontSize": 14；写成14.5或字符串"14"都会被忽略，回退到默认 - 修改后立即生效，无需重启 VSCode，但需保存
settings.json - 如果工作区目录下有
.vscode/settings.json，它会覆盖用户级设置，务必检查层级 - 某些主题（如 One Dark Pro）可能轻微压缩行高，但
workbench.fontSize仍起主导作用
window.zoomLevel 优先级更高，常掩盖字体调整
如果你改了 workbench.fontSize 却没看到变化，大概率是 window.zoomLevel 在“盖住”效果。这个设置是全局像素级缩放，优先级高于字体配置，会等比放大整个 UI 包括图标、按钮、菜单和状态栏。
- 确认当前值：
window.zoomLevel默认为0；设为1≈ 120%，2≈ 144% - 小数缩放（如
1.3）在中文字体下极易导致错位、截断、图标与文字不对齐，官方明确建议只用整数 - 快捷键
Ctrl + =/Ctrl + -实际就是修改window.zoomLevel，但只在编辑器焦点时生效；中文输入法状态下可能失效
别碰自定义 CSS，风险远大于收益
网上流传的通过 .monaco-list-row 或 .explorer 注入 CSS 强行调大资源管理器字体，短期看似有效，但本质是绕过 VSCode 渲染机制。
- VSCode 1.86+ 版本频繁重构 DOM 结构，选择器名（如
.part.sidebar）可能一更新就失效 - 自定义样式易与主题冲突，导致图标模糊、行高崩坏、甚至白屏
- 启用 Custom CSS 插件会触发安全警告，且每次升级后需手动重配，不可靠
- 官方文档明确声明：不支持用户修改内部 CSS，也不承诺兼容性
活动栏（Activity Bar）根本没法单独调字体
左侧最外层那一列图标文字（Explorer、Search、Git 等），没有 activityBar.fontSize 这类配置项，任何尝试都无效。这部分文字由 UI 框架自动缩放，只响应 window.zoomLevel。
-
editor.fontSize、terminal.integrated.fontSize对它完全无影响 - 远程开发（SSH/WSL）下，本地改了
settings.json，远程窗口也不会同步该区域 - 若真需要更大点击区域，换高对比度主题比硬调字体更稳定
workbench.fontSize，再清掉干扰它的 window.zoomLevel。其他路径要么被覆盖，要么下次更新就挂。
