@charset 不影响选择器匹配逻辑，其作用仅为声明 css 文件字符编码；若编码声明与实际文件编码不一致，会导致中文类名、id 等被错误解码为乱码（如“.用户菜单”变成“.û²˵”），从而无法匹配 html 元素。
@charset 对选择器没有直接影响。它不参与样式计算，也不改变选择器的匹配逻辑或优先级。
为什么有人觉得 @charset 影响了选择器？
实际是字符解码错误导致选择器“失效”——浏览器把 CSS 文件里本该是中文类名、ID 或属性值的字节，按错误编码解析成了乱码，结果 .用户菜单 变成 .û²˵，自然无法匹配 HTML 中真实的 class="用户菜单"。
常见诱因包括：
- CSS 文件保存为 GBK，但没写
@charset "GBK";，浏览器按 UTF-8 解析，中文类名全变乱码 - 写了
@charset "UTF-8";，但文件实际是 ANSI（Windows-1252）编码，BOM 缺失，浏览器误判 - 构建工具（如 Webpack、Vite）读取 CSS 时未指定 encoding，原始字节被错误转义后传给浏览器
@charset 必须出现在第一行且无前置空白
这是硬性限制。哪怕开头有一个空格、一个 BOM（除非是 UTF-8 BOM）、一行注释，@charset 都会被浏览器忽略，退回到自动推断编码——而推断往往失败。
正确写法只有一种：
@charset "UTF-8"; /* 其他规则从第二行开始 */
错误写法示例：
-
@charset "UTF-8";（前面有空格或制表符） -
/* 注释 */@charset "UTF-8";（注释在前） -
@charset'UTF-8';（单引号，必须双引号） -
@charset "utf-8" ;（分号前多空格，虽部分浏览器容忍，但不合规）
现代项目中其实很少需要手动写 @charset
原因很实际：
- 绝大多数编辑器（VS Code、WebStorm）默认保存为 UTF-8 且带 BOM 或无 BOM，浏览器能正确识别
- HTTP 响应头
Content-Type: text/css; charset=UTF-8的优先级高于@charset，服务端配好就不用管 - 构建工具（如 PostCSS、esbuild）默认以 UTF-8 读写 CSS，不会引入编码污染
只有当你明确要支持非 UTF-8 编码（比如遗留系统用 GB2312），或 CSS 文件由非标准流程生成（如模板拼接、脚本写入），才需要显式声明 @charset 并严格校验文件实际编码。
真正容易被忽略的点是：编码问题从不报错，只静默失配。检查控制台看不到警告，元素就是不生效——这时该先看网络面板里 CSS 的响应内容是否是乱码，而不是反复调选择器语法。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
