charset属性仅对外部js文件生效，优先级低于http响应头和bom；内联脚本忽略该属性；正确场景限于静态托管且服务器未设置charset响应头时。
charset 属性在 <script></script> 标签里只对**外部 JavaScript 文件**生效，且仅当浏览器无法从 HTTP 响应头或 BOM 推断编码时才起作用；它不能修复 HTML 主文档本身的乱码，也不能覆盖服务器返回的 Content-Type 中的 charset。
为什么 charset 在 <script></script> 里经常失效
浏览器解析外部脚本时，优先级顺序是：HTTP Content-Type 头 > BOM > <script charset></script>。只要服务器返回了 Content-Type: application/javascript; charset=gbk，哪怕你写 <script src="a.js" charset="UTF-8"></script>，浏览器也按 gbk 解析——结果还是乱码。
- Node.js/Express 默认不设
charset，响应头常为application/javascript（无charset），此时charset属性才可能被读取 - Webpack/Vite 构建产物默认 UTF-8 无 BOM，但若你用
iconv-lite转过码、或后端代理重写了响应头，charset就彻底被绕过 -
<script></script>内联代码（即没有src）完全忽略charset属性，它的编码由 HTML 主文档决定
<script charset></script> 的正确使用场景
它只在一种现实情况中可靠：静态托管（如 GitHub Pages、Netlify、S3）且 JS 文件本身保存为 UTF-8 无 BOM，但服务器没配 charset 响应头（比如返回 application/javascript 而非 application/javascript; charset=utf-8）。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 必须写全小写：
charset="utf-8"（大小写敏感，UTF-8或Utf-8在某些旧浏览器会失败） - 只能用于带
src的<script></script>，例如：<script src="/js/main.js" charset="utf-8"></script> - 不要和
type="module"混用——现代模块加载器忽略charset，只认 HTTP 头或 BOM
比 charset 更有效的三个动作
与其依赖 <script charset></script> 这个弱优先级机制，不如直接控制源头：
- 确保 JS 文件用编辑器存为
UTF-8 without BOM（VS Code 状态栏点编码 → “Save with Encoding” → 选UTF-8，不是UTF-8 with BOM） - 检查服务器是否返回
Content-Type: application/javascript; charset=utf-8（F12 → Network → 找 JS 请求 → Headers → Response Headers） - 如果用 Nginx，加配置：
location ~ \.js$ { add_header Content-Type "application/javascript; charset=utf-8"; }；Express 则在res.sendFile()前调用res.set("Content-Type", "application/javascript; charset=utf-8")
真正容易被忽略的是：JS 文件的编码声明和 HTML 文档的编码声明是两套独立系统，<meta charset="UTF-8"> 对外部 JS 完全无效；而一旦 JS 里含中文字符串（比如提示文案、正则字面量），编码错位就会直接导致语法错误或运行时乱码——这种问题往往卡在生产环境才暴露，调试成本远高于提前统一源头。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
