网页显示乱码，通常不是文字内容突然消失，而是网页实际使用的字符编码与浏览器、服务器或数据源声明的编码不一致。先判断乱码影响范围，再依次检查浏览器、网页响应头、HTML 文件、接口数据和字体，不要一开始就反复修改页面代码。临时恢复的条件是浏览器能够按正确编码重新解码；永久修复的条件是文件保存编码、服务器声明编码和数据传输编码保持一致。

先判断乱码出现在哪个范围

不同范围对应的故障位置不同。打开同一个网页，用其他浏览器或手机访问一次，可以快速缩小排查范围。

第一步：用可逆操作确认是否是浏览器问题

1. 重新加载页面。如果页面正在提交表单或编辑内容，先保存文字，避免刷新后丢失数据。
2. 用无痕窗口打开。无痕模式可以排除部分扩展、登录状态和本地缓存的影响。若无痕窗口正常，优先停用翻译、脚本管理、网页美化和广告拦截类扩展，再逐个恢复。
3. 换一个浏览器或设备测试。只有当前浏览器乱码，通常是缓存、扩展或本地设置；不同浏览器都乱码，则更可能是网页本身的编码问题。
4. 检查浏览器的字符编码选项。部分浏览器或旧网页仍提供编码切换功能，可以分别尝试自动识别、UTF-8 或与网页来源相符的中文编码。切换后必须重新加载页面，只有临时恢复时才说明原网页的编码声明可能不正确。
5. 清除该网站的缓存和站点数据。如果网站刚刚修复过，但当前设备仍显示旧页面，清理单个网站的数据比直接清空全部浏览记录更合适。

如果换浏览器后仍然出现相同乱码，不要继续反复切换浏览器设置，应转而检查网页实际返回的编码。浏览器只能按收到的字节进行解码，无法可靠修复已经错误转换的文字。

第二步：检查网页声明的编码是否与文件一致

网页通常同时受到三层编码信息影响：服务器响应头、HTML 文档中的字符集声明，以及 HTML 文件本身保存时采用的编码。三者不一致，就可能出现中文变成“中”之类的乱码，也可能出现问号或无法识别的符号。

检查服务器响应头

在浏览器开发者工具中打开网络请求，选中页面对应的文档请求，查看响应头中的 Content-Type。正常的 HTML 页面应明确声明文档类型和字符集，例如页面实际使用 UTF-8 时，应返回类似 text/html; charset=UTF-8 的信息。若响应头写成其他编码，浏览器可能优先按照响应头解码，即使 HTML 文件内部写了 UTF-8，也仍然会显示乱码。

如果页面由服务器程序或模板系统输出，应在统一的响应配置中修正编码，而不是只修改某一个页面。服务器声明的编码必须与页面实际字节一致；仅把响应头改成 UTF-8，而文件仍然以其他编码保存，可能会让乱码更加明显。

检查 HTML 中的字符集声明

HTML 文档应在较靠前的位置声明字符集，常见写法是 <meta charset="UTF-8">。这项声明需要位于文档头部，并且要和服务器响应头保持一致。对于历史页面，如果文件实际保存为 GBK 或 GB18030，就不能只把 meta 标签改成 UTF-8；应先将文件转换并保存为 UTF-8，再统一修改声明。

检查时可以直接查看网页源文件，确认中文在编辑器中是否正常。如果编辑器打开源文件时已经乱码，说明问题发生在文件保存或读取阶段；如果源文件正常而浏览器显示乱码，应重点查看服务器响应头、模板输出和缓存。

第三步：统一文件、模板和后端输出编码

网页不是只有一个编码点。静态 HTML、公共模板、CSS 内容、JavaScript 文件、后端输出以及数据库连接，都可能参与文字传递。修复时应从文字产生的位置一直检查到浏览器接收的位置。

• 静态 HTML：确认编辑器显示中文正常，并将文件统一保存为 UTF-8，避免同一网站混用多种保存编码。
• 模板文件：检查公共头部是否重复输出了不同的字符集声明，或某个旧模板覆盖了新模板的设置。
• 服务器输出：确认动态页面返回的 Content-Type 与模板及文件编码相同。
• 样式和脚本：如果乱码只出现在由脚本插入的文字，检查脚本文件本身、接口响应以及前端解码方式。
• 数据库连接：确认数据库、数据表、连接参数和查询结果使用兼容的字符集。数据库连接编码错误时，页面模板可能正常，查询出来的中文却单独乱码。

如果网站使用旧的 GBK 编码，最稳妥的做法不是只更换其中一层，而是确认旧数据、程序连接和响应声明全部一致；如果准备迁移到 UTF-8，则应先备份数据，再统一转换文件、数据库和接口，最后进行页面验证。

第四步：只有接口或局部内容乱码时，检查数据链路

如果网页标题和固定文字正常，只有评论、列表、搜索结果或用户资料乱码，问题通常不在浏览器，而在接口或数据库。先在开发者工具中查看接口的原始响应：如果接口返回内容本身已经乱码，应检查接口服务、数据库连接和数据转换；如果接口原始内容正常，但页面插入后乱码，应检查前端读取响应的方法以及是否发生了重复解码。

接口返回格式也要与实际内容匹配。JSON、HTML 和纯文本的响应类型不能混用，服务端应返回准确的内容类型，前端也应使用对应的读取方式。不要对已经正确解码的字符串再次进行编码转换，否则可能把正常中文再次变成乱码。

如果数据库中保存的内容本身已经是乱码，修改网页的 meta 标签或响应头不能恢复原文。这时需要从备份、原始导入文件或上游数据重新获取正确文字，再修复写入流程；继续调整浏览器编码只能改变显示方式，无法还原已经被错误替换的字符。

出现方框或问号时，不要只按网页编码处理

中文变成连续方框、空白方块或部分生僻字缺失，可能是字体不包含对应字符，而不是 UTF-8 或 GBK 设置错误。可以先换一台设备或浏览器验证，再检查页面的 font-family 配置、系统中文字体和网页字体文件是否加载成功。

如果文字变成问号，需进一步判断问号是在网页生成前还是生成后出现的。源文件、接口响应或数据库中已经是问号，说明字符在保存或传输阶段被替换；只有浏览器画面显示问号，则继续检查字体、解码和页面资源。不要把字体缺失与编码不一致混为同一种故障。

修改后仍乱码：清理缓存并验证新响应

编码配置修正后，旧的 HTML、接口响应或静态资源可能仍被浏览器、反向代理、CDN 或 Service Worker 缓存。此时应先执行强制刷新，再清理该站点的缓存；如果网站有缓存服务，还要刷新对应资源。修改后的页面必须确认网络请求返回的是新内容，而不是仅仅看到本地缓存的旧页面。

验证时至少检查以下情况：

• 同一页面在普通窗口和无痕窗口都能正常显示。
• 换用另一种浏览器或移动设备访问，中文仍然正常。
• 页面响应头、HTML 字符集声明和文件实际保存编码一致。
• 固定文字、接口数据、表单提交结果和数据库查询结果均无乱码。
• 刷新页面、退出重新进入以及清理缓存后，显示结果保持一致。

按照“先判断范围，再排除浏览器，随后检查响应头、HTML 文件、接口和数据库，最后清理缓存”的顺序处理，通常可以定位网页显示乱码的具体环节。临时切换编码只能作为诊断手段；要让问题稳定恢复，必须让文字从产生、保存、传输到显示的每一层使用一致且正确的编码。