在WebStorm中遇到文件乱码，通常并非您未设置编码，而是IDE的自动识别机制出现了偏差。解决问题的关键在于主动、明确地告知WebStorm使用何种编码来解析文件，而非依赖其并不总是准确的猜测。
File Encoding 状态栏点击后选 Reload 还是 Convert？
当您打开一个显示乱码的JS或HTML文件时，首先应查看编辑器右下角的状态栏。这里会显示WebStorm当前“认为”的编码格式，例如GBK或ISO-8859-1。点击该编码标识，会弹出可选编码列表。
关键决策点在于：当您选择列表中带有⚠️警告标记的编码（如GBK）时，WebStorm会弹出对话框，要求您在Reload和Convert之间做出选择。
- Reload（重新加载）：此操作仅改变编辑器显示文件内容的方式，不会修改磁盘上的原始文件。它相当于一次“安全预览”，用于验证选择该编码后，文件内容是否能被正确解码并恢复正常显示。
- Convert（转换）：此操作更为彻底。它会按照您选定的新编码，将文件内容重新编码并写入磁盘。执行前，您必须百分之百确认文件的原始内容就是此编码，否则一旦选错，文件中的中文等字符可能永久变为问号或乱码，造成不可逆的损坏。
- 一旦执行
Convert，WebStorm便会记住该文件与所选编码的绑定关系，后续打开时将直接使用此编码，不再进行猜测。
Global Encoding 和 Project Encoding 都设成 UTF-8 就够了吗？
将全局编码和项目编码均设置为UTF-8是基础步骤，但远非一劳永逸。核心问题在于WebStorm有一套复杂的编码回退机制，任何一环设置不当都可能导致前功尽弃。
- 首先，确保
Global Encoding（位于File -> Settings -> Editor -> General）和Project Encoding（位于File -> Settings -> Editor -> File Encodings）均已设置为UTF-8。 - 其次，切勿忽略
Default encoding for properties files这一项。若未设为UTF-8，.properties文件中的中文可能会被静默转换为类似\u4f60\u597d的Unicode转义序列，且无任何提示。 - 对于Java属性文件，务必勾选下方的
Transparent native-to-ascii conversion选项，这是确保其正确显示的关键开关。 - 完成上述设置后，点击
OK。最稳妥的做法是重启一次WebStorm，因为部分编码设置需要重启IDE才能完全生效，热加载有时并不可靠。
为什么编辑器里正常，Terminal 或 Run Configuration 输出还是乱码？
这是另一个常见误区。编辑器内部显示正常，仅说明文件本身的编码解析无误。但Terminal或运行配置的输出乱码，根源在于输出流由JVM或系统命令行环境控制，与IDE的编辑器设置相互独立。
- 对于Windows用户：需要在注册表路径
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor下，新增一个名为Autorun的字符串值，并将其数据设置为chcp 65001。这能确保命令行终端默认使用UTF-8代码页。 - 修改JVM参数：找到WebStorm的安装目录，编辑
bin/webstorm64.exe.vmoptions文件（macOS/Linux下为webstorm.vmoptions），在文件末尾追加一行：-Dfile.encoding=UTF-8。 - 检查运行配置：在具体的
Run Configuration中，查看Environment Variables一栏，确保已添加file.encoding=UTF-8。IntelliJ IDEA系列工具的运行配置经常遗漏此设置。 - 这三处设置环环相扣，缺一不可。若仅修改IDE编码，
console.log(“你好”)在Terminal中输出时，很可能仍显示为乱码。
JS 文件本身带 BOM 或
当文件自身包含编码声明时，WebStorm会赋予这些声明最高优先级，直接覆盖您在全局或项目中的设置。
- 若一个UTF-8文件包含BOM（字节顺序标记），状态栏将直接显示
UTF-8，即使您将全局编码设为GBK也无济于事。 - 同理，若HTML文件中包含
声明，WebStorm将强制使用GBK解析该文件，即使文件在磁盘上实际以UTF-8格式存储。 - 遇到此类文件内部声明与预期编码冲突的情况，解决方案通常有二：要么删除HTML中的meta声明，要么手动点击状态栏，选择
UTF-8后执行Convert操作（前提是您确信文件内容原本就是UTF-8编码）。 - BOM本身通常不影响JavaScript执行，但部分旧版构建工具（如老版本Webpack）可能因此抛出警告。从代码规范角度出发，建议统一移除BOM。
归根结底，解决WebStorm编码问题的真正难点，并非“如何设置”，而是“厘清究竟是哪一层设置覆盖了您的预期”。BOM标记、HTML meta标签、JVM启动参数、系统控制台代码页……这其中的每一层，都可能在您不知情的情况下，悄然决定了最终的编码呈现结果。
