资源管理器字体大小由 workbench.fontSize 控制，该设置影响侧边栏所有树形控件，无法单独调整；需在 settings.json 中设为整数（如 "workbench.fontSize": 14），修改后立即生效。
VSCode 资源管理器字体大小由哪个设置控制
资源管理器（Explorer）的字体大小不单独存在，它继承自 workbench.fontAliasing 和全局 editor.fontSize 的间接影响，但真正起效的是 workbench.tree.indent 无关、explorer.fontFamily 不存在——唯一有效路径是修改 workbench.fontSize。
这个设置同时影响侧边栏所有树形控件（包括资源管理器、搜索结果、大纲、扩展列表），不能只调资源管理器。想“只改文件列表”，VSCode 原生不支持。
-
workbench.fontSize是核心开关，值为数字（如13），默认通常为12或系统继承值 - 修改后需手动刷新：保存设置后，资源管理器会立即响应，无需重启
- 如果设置了
editor.fontSize，它不会影响资源管理器；两者完全独立
在 settings.json 中直接修改 workbench.fontSize
图形界面设置有时同步滞后或被工作区设置覆盖，直接编辑配置文件最可靠。
打开命令面板（Ctrl+Shift+P / Cmd+Shift+P），输入并执行 Preferences: Open Settings (JSON)，在花括号内添加或修改：
{
"workbench.fontSize": 14
}
- 值必须是整数，小数（如
13.5）会被忽略，回退到默认 - 如果已有同名设置在工作区（
.vscode/settings.json），它会优先于用户级设置，注意检查层级 - 某些主题（如
Nord、One Dark Pro）可能硬编码了部分尺寸，此时workbench.fontSize仍生效，但图标间距可能显得拥挤
为什么调了没反应？常见干扰项
改完 workbench.fontSize 却没变化，大概率不是设置错了，而是被其他因素覆盖或误判了效果。
- 缩放级别（
window.zoomLevel）优先级更高：如果设了2或-1，它会整体放大/缩小整个窗口，掩盖字体微调——先确认window.zoomLevel是0 - 系统 DPI 缩放（Windows/macOS）可能导致 VSCode 渲染异常，尤其外接高分屏时；可尝试在快捷方式属性中勾选“替代高 DPI 缩放行为”
- 用了自定义 CSS 注入插件（如
Custom CSS and JS Loader），它们可能重写了.monaco-list-row字体规则，优先级高于设置 - 误把
editor.fontFamily或terminal.integrated.fontSize当成资源管理器设置，改了也没用
想更精细控制？只能靠 CSS 注入（不推荐）
VSCode 官方明确不提供细粒度字体控制 API，所谓“仅调资源管理器”只能通过注入自定义 CSS 实现，但风险明显：
- 每次 VSCode 更新都可能破坏选择器（如从
.explorer-folders-view变成.explorer-viewlet），导致样式失效甚至布局错乱 - 需要启用
Custom CSS and JS Loader插件，该插件已被标记为“不安全”，且 VSCode 1.86+ 默认禁用未签名扩展 - 若真要试，最小侵入写法是：
.monaco-list .monaco-list-row { font-size: 14px !important; }，但仅限临时调试，别进团队项目
字体大小这事，原生能控的就只有 workbench.fontSize 这一个杠杆。想单点突破，等于在引擎盖下拧螺丝修空调——位置不对，力道再准也没用。
