项目级 files.associations 更可靠，因其优先级高于用户级，可避免全局规则污染其他项目；VSCode 匹配顺序为工作区 → 用户 → 内置 → 扩展，且仅当项目根目录下存在 .vscode/settings.json 并正确配置时才生效。
为什么项目级 files.associations 比用户级更可靠？
工作区配置（即项目根目录下的 .vscode/settings.json）优先级高于用户级设置，能避免全局规则污染其他项目。比如你在一个 Node 项目里用 .env.local，但在 Python 项目里又不想它被识别为 dotenv —— 全局配一次就全中招，而工作区配只生效于当前目录树。
VSCode 的匹配顺序是：工作区 → 用户 → 内置 → 扩展。只要项目里有 .vscode/settings.json，里面的 files.associations 就会覆盖掉你用户设置里的同名规则。
- 工作区配置路径必须是项目根目录下的
.vscode/settings.json，不是任意子目录 - 如果项目已有该文件，直接在
"files.associations"对象里追加键值对即可 - 若整个项目没
.vscode目录，手动创建.vscode/settings.json并写入完整 JSON 对象（含外层{}）
files.associations 在工作区里怎么写才不踩坑？
格式看着简单，但几个细节错一个，规则就静默失效：
- 键必须是字符串，支持
*（任意字符）、?（单个字符），但不支持**或正则；例如".env.*"匹配.env.development，但"*.env.*"会错配foo.env.bar - 值必须是 VSCode 内部注册的
languageId，大小写敏感、无空格；比如dotenv是对的，DotEnv或dotenv file都无效 - 多个规则不要合并成数组：
"*.conf": ["ini", "shellscript"]是错的，只会取第一个且可能被忽略；应拆成两条独立键值对 - 通配符前后不加空格，引号必须是双引号，JSON 末尾不能有多余逗号
正确示例：
{
"files.associations": {
"*.conf": "ini",
".env.*": "dotenv",
"Dockerfile.*": "dockerfile",
"nginx.conf": "nginx"
}
}
如何确认语言 ID 是否填对？
别猜，也别搜“VSCode nginx 语言名”——最稳的方式是让 VSCode 自己告诉你：
- 先打开一个已知能高亮的同类文件（比如真实的
nginx.conf，或装了 Nginx 扩展后能识别的配置文件） - 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），输入Change Language Mode回车 - 下拉列表里显示的名称就是你要填的
languageId，比如看到Nginx，就填nginx；看到Python，就填python - 如果列表里没有目标语言，说明对应扩展没启用，或该语言模式根本没加载（比如
nginx需要安装DavidAnson.vscode-markdownlint以外的 Nginx 插件）
改完为什么文件还是没变语言模式？
VSCode 不会热更新已打开文件的语言模式，这是最容易卡住人的点：
- 保存
.vscode/settings.json后，必须关闭再重新打开对应文件（不是刷新，是关掉 tab 再从资源管理器双击/打开） - 如果文件已打开，可用命令面板运行
Developer: Reopen with Language Mode，手动选一次目标语言，再点“始终使用此语言” - 检查右下角状态栏——那里显示的才是真实生效的语言模式，不是文件后缀
- 若仍不对，打开命令面板运行
Developer: Toggle Developer Tools，看 Console 里有没有Failed to resolve language类报错，基本就是languageId拼错了
真正起作用的永远是右下角那个小标签，而不是你脑补的“它应该认识这个后缀”。
