现代浏览器已忽略或标签的charset属性，其解析完全依赖文件BOM和HTTP响应头中的Content-Type charset参数，该属性在HTML5中已被废弃。

外部JS/CSS文件的charset属性是否有效

HTML里给<script></script>或<link>标签加charset属性，**现代浏览器已忽略它**。比如<script src="app.js" charset="UTF-8"></script>中的charset不会影响解析行为，Chrome、Firefox、Safari均按HTTP响应头或BOM推断编码，该属性在HTML5中已被废弃。

真正起作用的是文件实际编码 + HTTP响应头

浏览器加载外部JS/CSS时，只认两个东西：文件本身的字节流（含BOM）和服务器返回的Content-Type响应头里的charset参数。两者不一致时，以响应头为准——哪怕JS文件是UTF-8无BOM，响应头写charset=GBK，浏览器就用GBK解码，必然报Uncaught SyntaxError: Invalid or un之类错误。

Wechat Article Html

将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。

下载

• 检查响应头：打开DevTools → Network → 找到JS/CSS请求 → 看Response Headers里的Content-Type，确认含charset=utf-8
• Nginx配置示例：location ~ \.js$ { add_header Content-Type "application/javascript; charset=utf-8"; }
• Express配置示例：res.set("Content-Type", "application/javascript; charset=utf-8");
• 本地双击打开（file://协议）时无响应头，全靠文件BOM或默认编码，务必避免

JS文件里中文注释/字符串乱码的典型原因

不是<script></script>标签没写charset，而是下面三者之一出错：

• JS文件本身保存为GBK或ANSI，但HTML声明了UTF-8，且服务端没覆盖响应头
• JS文件有UTF-8 BOM（EF BB BF），某些构建工具（如Webpack旧版）会把BOM当非法字符报错
• HTML页面用了meta charset="UTF-8"，但JS文件被CDN缓存了旧版本（响应头仍是charset=iso-8859-1）
• Vue/React等框架动态插入<script></script>时，未控制其加载时机，导致DOM解析早于charset声明

如何验证并修复CSS里的中文显示异常

CSS文件同理，但更隐蔽：即使@font-face或content: "中文"写对了，若CSS响应头缺失charset，浏览器可能用ISO-8859-1解码，把中变成。验证步骤：

• 直接访问CSS URL（如https://site.com/style.css），看浏览器地址栏是否正常显示中文
• 用curl -I https://site.com/style.css查响应头，确认Content-Type: text/css; charset=utf-8
• VS Code打开CSS文件，右下角确认编码显示UTF-8（不是UTF-8 with BOM）
• 避免在CSS里写@charset "UTF-8";——这是CSS2语法，现代浏览器不依赖它，且若文件已有BOM，反而可能冲突

文件编码、响应头、HTML声明这三者必须严格对齐，少一个都可能让中文在JS/CSS里变成或报错，而问题往往不出在HTML标签上。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！