PHP文件应为UTF-8无BOM编码，Dreamweaver因对BOM敏感易致乱码、header失效或空白页；须确保文件编码为UTF-8 without BOM、header('Content-Type...')前置无空白、HTML中兜底、数据库连接使用utf8mb4、服务端default_charset设为"utf-8"。
PHP文件本身是不是UTF-8无BOM？
DW（Dreamweaver）打开PHP文件显示乱码，最常见原因是文件保存时带了BOM头，或根本不是UTF-8编码。DW对BOM极其敏感，哪怕开头多一个不可见字节，都可能让整个页面输出异常，甚至导致header()调用失败、空白页或中文变问号。
- 在DW中：菜单 → 文件 → 另存为 → 点击“编码”下拉框，选
UTF-8（不带签名）或UTF-8 without BOM - 更可靠的做法是：用VS Code或Sublime Text重新打开该文件，右下角确认编码显示为
UTF-8（不是UTF-8 with BOM），然后“另存为”并勾选“无BOM”选项 - 已有多个PHP文件？可用命令行批量清理BOM：
find . -name "*.php" -exec sed -i '1s/^\xEF\xBB\xBF//' {} \;（Linux/macOS）
HTTP响应头和HTML meta有没有双保险？
DW本地预览（比如用内置浏览器或Live View）不走Apache/Nginx，它直接读取PHP文件并执行，但不会自动注入Content-Type头——所以即使你写了header()，若DW没正确触发PHP解析（比如双击打开而非通过Web服务器运行），就完全不起作用。
- 必须确保PHP脚本第一行可执行代码就是：
header('Content-Type: text/html; charset=utf-8');，且前面**绝对不能有任何空格、空行、echo或BOM** - 同时在HTML的
里加：<meta charset="utf-8">，这是给浏览器兜底用的，尤其DW Live View依赖这个 - 别写成
charset=GBK或漏掉引号，也别放在里——位置错或写法错等于没写
数据库查询结果乱码？检查连接层编码是否同步
如果你的PHP页面从MySQL读中文，在DW里跑出来是乱码（比如显示成“æ们”），问题几乎一定出在连接字符集没设对，而不是文件编码。
- 用
mysqli时，连接后立刻执行：$mysqli->set_charset('utf8mb4');（注意是utf8mb4，不是utf8） - 用
PDO时，DSN里必须显式声明：mysql:host=localhost;dbname=test;charset=utf8mb4 - 千万别只改表结构为
utf8mb4，却忘了连上数据库那一刻就用SET NAMES utf8mb4——那数据在传输途中就被MySQL按latin1转了一道，救不回来
为什么DW里看着正常，网页却乱码？
因为DW的“实时视图”或“在浏览器中预览”功能，有时会绕过PHP解析器，直接把PHP源码当纯HTML渲染（尤其当你没配好本地服务器时）。这时你看到的“中文正常”，其实是DW在用自己的编码逻辑硬解，不代表真实环境能跑通。
立即学习“PHP免费学习笔记（深入）”；
- 验证方式：把PHP文件放到
localhost下（如XAMPP/MAMP），用http://localhost/test.php访问，这才是真实链路 - 如果这时乱码，说明问题在服务端配置；如果DW里乱码但localhost正常，说明DW没走PHP解析，只是文本渲染——那就别信DW的预览，以浏览器真实请求为准
- 顺手检查
php.ini里的default_charset是否设为"utf-8"，否则某些未显式设header的脚本会退回到ISO-8859-1
header()也写了，meta也加了，结果数据库连接用的是utf8而不是utf8mb4，emoji和生僻字照样炸成。全程统一，少一个都不算闭环。 
