http-equiv="Content-Type"不能重定向，因其仅声明MIME类型与字符编码（如text/html; charset=utf-8），不触发跳转；真正实现跳转的是http-equiv="Refresh"。
http-equiv="Content-Type" 不是重定向机制，它只声明字符编码；所谓“重定向”是混淆了 http-equiv="Refresh" 的功能。
为什么 http-equiv="Content-Type" 不能做重定向
这个属性本质是模拟 HTTP 响应头 Content-Type，仅用于告知浏览器：“本页 MIME 类型是 text/html，用 charset=utf-8 解码”。浏览器收到后不会跳转、不发新请求、不改变 URL。
- 若误写成
<meta http-equiv="Content-Type" content="text/html; url=https://example.com">，浏览器直接忽略该值，因为url=...不是合法的Content-Type参数 - 真正触发页面跳转的是
http-equiv="Refresh"，例如<meta http-equiv="Refresh" content="0;url=/new-page.html"> - 现代标准（HTML5）已明确不鼓励用
Refresh做跳转，既影响可访问性，也常被搜索引擎视为软重定向或 spam
http-equiv="Content-Type" 在旧版字符集中的实际作用
它解决的是“页面打开后中文/日文/繁体字显示为方块或问号”的根本问题——即解码失败。关键在于：它只在没有 HTTP 响应头覆盖时才生效。
- 如果服务器返回了
Content-Type: text/html; charset=gb2312，那么 HTML 里的<meta http-equiv="Content-Type" content="text/html; charset=utf-8">会被完全无视 - 静态托管（如 GitHub Pages、Netlify）默认不发
charset，此时meta是唯一可靠声明方式 - 老系统（如 IE6–8）对
<meta charset="utf-8">（HTML5 简写）支持差，必须用完整http-equiv形式 -
gb2312、big5、shift_jis等非 UTF-8 编码，必须确保文件本身保存为对应编码，否则声明再准也白搭
容易被忽略的冲突点：HTTP 响应头优先级永远高于 meta
这是最常踩的坑：改了 meta 没用，不是写错了，而是服务器头已经锁死了编码。
立即学习“前端免费学习笔记（深入）”；
- 用浏览器开发者工具的 Network → Response Headers 查看是否含
Content-Type: ... charset=... - Apache 用户检查
.htaccess是否有AddDefaultCharset；Nginx 用户确认charset指令未全局强制 - 本地测试时用
python3 -m http.server启的服务默认不带 charset 头，此时meta生效；但换成 XAMPP/MAMP 就可能自动加charset=ISO-8859-1，导致 UTF-8 页面乱码 - 即使
meta和响应头都写了 UTF-8，若文件实际是 GBK 编码保存，浏览器仍会按 UTF-8 解——结果就是每个汉字变两三个乱码字符
真正要“重定向”，别碰 Content-Type；真要兼容老字符集，别只改 meta，得同步核对文件编码、服务器配置、响应头三者是否一致。
