script 标签的 charset 属性仅对 src 引入的外部 js 文件生效，用于显式声明其物理编码；内联脚本编码由 html 文档 charset 决定，且 charset 值必须与文件真实编码严格一致，否则仍会乱码。
script 标签的 charset 属性本身不用于“处理”古老编码，而是用来**显式告知浏览器：这个外部 JS 文件实际用的是什么编码**。当你的 .js 文件保存为 GBK（比如老系统生成、旧编辑器导出），而 HTML 页面声明为 UTF-8 时，不加 charset 或写错，浏览器很可能按 UTF-8 解码 GBK 字节，导致中文乱码——这时 charset 就是关键补救手段。
charset 属性只对 src 引入的外部脚本生效
它完全不作用于内联 script（即写在 <script>...</script> 里的代码）。如果你的 JS 逻辑写在 HTML 里，那它的编码完全由 HTML 文档本身的 <meta charset="UTF-8"> 决定，和 script 的 charset 无关。
- ✅ 正确场景：
<script src="old-tool.js" charset="GBK"></script>（old-tool.js 确实是 GBK 编码保存） - ❌ 无效写法：
<script charset="GBK">alert("你好");</script>（charset 被忽略）
charset 值必须与文件物理编码严格一致
写 charset="GBK" 没用，如果文件实际是 UTF-8-BOM 或 ANSI（Windows 记事本默认），照样乱。确认方式不是看文件名或注释，而是用编辑器查看真实编码：
- VS Code 右下角状态栏显示 “GBK”、“UTF-8” 或 “UTF-8 with BOM”
- Notepad++：菜单「编码」→ 当前选中项即为真实编码
- 命令行验证（Linux/macOS）：
file -i old-tool.js或enca -L zh old-tool.js
浏览器解析优先级与兼容性注意事项
charset 属性虽被所有主流浏览器支持，但它在解析链中位置靠后：
- HTTP 响应头
Content-Type: application/javascript; charset=GBK优先级最高（服务器配置决定） - 其次才是
<script charset="GBK"></script> - 若两者冲突，以响应头为准；若都没有，浏览器会按 HTML 主文档 charset 或自身启发式检测推断
- 注意：IE 和旧版 Edge 对 GBK 支持更稳定；现代 Chrome/Firefox 默认倾向 UTF-8，遇到 GBK 文件若无明确提示，可能静默失败或显示
更推荐的长期解法：统一转为 UTF-8
依赖 charset="GBK" 是临时方案，存在维护风险：
- 不同编辑器对 GBK 解析细节有差异（尤其含全角标点或生僻字时）
- CDN 或构建工具可能自动转码，破坏原始字节
- Node.js 等服务端环境默认 UTF-8，混用 GBK 易引发 pipeline 错误
- 建议用 Notepad++ 或 VS Code 将 JS 文件另存为 “UTF-8 无 BOM”，同时把 script 标签中的 charset 属性删掉——最简、最稳
