网页显示乱码，通常不是文字内容突然消失，而是页面实际编码、服务器声明的编码、浏览器解析方式或字体支持不一致。排查时不要先反复刷新或直接修改数据库，应该先判断乱码出现在哪一层：是整个网页都异常、部分文字异常，还是只有方框和问号。确认范围后，再依次检查浏览器、响应头、HTML 声明、文件保存编码和数据源，通常可以较快定位原因。
先判断乱码的具体表现
先在当前页面执行一次强制刷新，再用无痕窗口或另一款浏览器打开同一页面。如果只有当前浏览器异常，而其他浏览器正常，优先处理缓存、扩展程序或浏览器编码设置；如果所有设备打开都乱码，问题更可能出在服务器、页面文件或数据输出环节。
| 表现 | 优先怀疑的位置 | 常见恢复条件 |
|---|---|---|
| 整页中文变成问号、奇怪符号 | 响应头、HTML 编码声明、文件保存编码 | 各层统一使用同一种编码，并重新加载页面 |
| 只有数据库或接口返回的文字乱码 | 数据库连接、接口响应或程序转码 | 输入、存储、读取和输出编码保持一致 |
| 只有少数字符显示成方框 | 字体或字形文件缺失 | 浏览器能加载包含目标字符的字体 |
| 刷新后偶尔正常，重新打开又乱码 | 缓存、代理、压缩资源或不同页面版本 | 缓存清除，且实际返回内容与声明保持一致 |
第一步：排除浏览器本地问题
- 强制刷新页面。页面更新过编码后，浏览器可能仍使用旧的 HTML 或样式缓存。刷新后仍异常，再清理该站点的缓存，而不是一开始就清除所有浏览数据。
- 关闭扩展程序测试。翻译、阅读模式、脚本拦截和页面美化扩展可能修改文本或注入样式。使用无痕窗口打开，可以快速判断是否由扩展造成。
- 切换浏览器或设备。如果只有一台电脑出现乱码，重点检查浏览器设置、系统字体和本地代理；如果不同浏览器都一样，则不应继续把时间集中在客户端设置上。
- 临时切换网页编码。部分浏览器提供手动选择编码的功能，可以尝试 UTF-8 或与旧页面匹配的中文编码。手动切换后恢复，只能说明页面声明可能有问题，并不代表根治；重新打开页面仍应能够自动正确识别。
如果页面源代码本身已经是乱码，修改字体通常没有效果；如果源代码中的中文正常，只是页面渲染后异常，再继续检查 HTML 声明和样式。这个判断可以避免在错误的层面反复调整。
第二步：检查服务器响应头和网页编码声明
浏览器接收网页时，会参考服务器返回的响应头。HTML 页面通常应返回类似“Content-Type：text/html；charset=UTF-8”的编码声明。响应头中的字符集应与实际文件编码一致，否则浏览器可能在读取页面之前就采用错误的方式解释字节。
检查时重点看以下几项：
- 服务器返回的内容类型是否为 HTML，而不是错误的文本类型或下载类型。
- 字符集是否明确声明，且大小写和写法没有导致配置失效的问题。
- 响应头声明的编码是否与页面文件真实保存编码一致。
- 不同缓存节点、反向代理或 CDN 是否返回了不同版本的响应头。
页面内部也应尽早声明字符集。HTML 文档的字符集声明应放在文档头部靠前的位置，并且全站尽量只保留一种明确的声明。不要一部分页面使用 UTF-8，另一部分页面依赖浏览器猜测；也不要同时留下互相矛盾的多个编码声明。
需要注意的是，修改 HTML 中的编码声明并不会自动转换文件内容。如果文件实际以一种旧编码保存，却只把声明改成 UTF-8，乱码可能更加严重。正确做法是先确认文件的真实编码，再用编辑器或构建工具将文件转换为目标编码，最后同步修改响应头和页面声明。
第三步：确认页面文件没有被错误转换
如果服务器配置看起来正确，但页面仍然乱码，应直接检查静态 HTML、模板文件、JavaScript 文件或接口响应中的原始内容。常见错误包括：编辑器打开文件时选错编码、保存时重复转换、上传工具改变文件编码，以及部署时混入旧版本文件。
建议选取一段固定中文作为测试内容，分别检查本地源文件、部署后的文件和浏览器收到的响应。若本地文件正常、部署后异常，问题通常在上传、构建或服务器配置；若部署文件本身已经异常，应回到源文件或版本库恢复正确版本。
不要仅通过修改文件扩展名或文件名来“转换编码”。扩展名不改变文件内部字节，必须使用能够识别并转换字符编码的编辑器或构建工具。转换前保留备份，并先在测试环境验证，避免把原本可恢复的内容覆盖成不可逆的乱码。
第四步：单独排查接口、数据库和表单数据
如果网页标题、菜单和静态文字正常，只有文章正文、用户昵称或接口返回内容乱码，问题一般不在浏览器，而在动态数据链路。应按“输入、存储、读取、输出”的顺序检查，而不是只改最后一层。
- 输入环节：表单提交、文件导入或接口请求使用的编码要明确，不能让程序依赖默认设置。
- 存储环节：数据库、数据表和字段应支持目标字符集，字符排序规则也应与应用配置相容。
- 读取环节：应用连接数据库时要明确设置连接编码，避免数据库能正确存储，程序读取时却按另一种编码解释。
- 输出环节：接口返回的 JSON、文本或 HTML 应声明正确的字符集，前端也要按相同编码解析。
如果数据库里看到的文字已经是“?¤?–”一类重复转码结果，或已经变成问号，不能直接对全部数据再次转换。先备份数据，确认原始字节、历史备份和转码次数，再对少量样本测试。已经被替换成问号的字符通常无法仅靠浏览器恢复，需要从原始数据或备份中找回。
第五步：区分编码乱码与字体缺字
并非所有异常都属于编码错误。若文字位置出现空心方框、方框内带叉号，或者只有生僻字、特殊符号无法显示，而普通中文和英文正常，更可能是当前字体没有对应字形。此时可以检查页面的字体设置、系统字体和网页字体文件是否成功加载。
字体问题的恢复条件是：页面编码已经正确，浏览器能够获得包含目标字符的字体，并且字体文件没有加载失败或被安全策略拦截。不要为了修复字体问题反复修改 UTF-8 或 GBK；编码正确但字体缺字时，改编码通常不会产生改善。
检查后如何确认已经恢复
修复后不要只看首页是否正常，应同时验证静态文字、动态数据、特殊符号和表单提交。使用原来的浏览器重新打开页面，并在无痕窗口、另一款浏览器中复查，确认页面不依赖手动选择编码才能显示。
- 响应头、HTML 声明和实际文件编码一致。
- 刷新、关闭页面后重新打开，文字仍能正常显示。
- 文章正文、数据库字段和接口返回内容没有单独乱码。
- 中文标点、数字、特殊符号和生僻字按预期显示。
- 新提交的表单数据不会再次产生问号或异常字符。
如果只有一个网站乱码，优先检查该站点的缓存、响应头和部署文件；如果多个网站都乱码，优先检查浏览器、系统字体或本地网络环境；如果只有数据库内容异常，则沿着应用数据链路排查。按照这个顺序，可以先排除低成本的客户端问题，再定位到编码声明、文件内容和动态数据，恢复后也能确认问题没有在刷新或重新提交时再次出现。
