X-Content-Type-Options: nosniff 对 HTML 无效，仅作用于 JS/CSS 等外链资源；它强制浏览器禁用 MIME 嗅探，防止 text/plain 等响应被误执行为脚本，必须由服务器在 HTTP 响应头中设置，meta 标签无效。
为什么 X-Content-Type-Options: nosniff 在 HTML 场景下几乎没用
它根本不是给 HTML 本身加的防护，而是告诉浏览器：别猜我返回的资源类型。HTML 文件（text/html）由服务器明确声明 MIME 类型，浏览器不会去 sniff；真正需要它的，是那些可能被误判为 HTML 的“非 HTML 资源”，比如用户上传的 .txt、.js 或 .css 文件，却被服务端错误地返回了 text/plain —— 此时浏览器若开启 MIME sniffing，可能把纯文本当 HTML 执行，导致 XSS。
哪些响应头位置能生效？优先级怎么排？
必须由服务器在 HTTP 响应头中设置，HTML 的 <meta http-equiv> 完全无效（Chrome/Firefox/Edge 均忽略）。常见错误是写成：
<meta http-equiv="X-Content-Type-Options" content="nosniff">
这毫无作用。正确方式只有：
- Web 服务器配置（Nginx/Apache）
- 后端代码动态输出（如 Node.js 的
res.setHeader()、Python Flask 的response.headers['X-Content-Type-Options'] = 'nosniff'） - CDN 或反向代理层（如 Cloudflare Rules、AWS ALB Listener Rule）
Nginx 和 Apache 怎么加才不踩坑
关键是作用域和继承关系。很多人只在 server 块里加，结果静态资源（如 /static/js/app.js）走的是 location ~ \.js$ 块，覆盖了父级 header。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- Nginx：推荐在
http或server块用add_header X-Content-Type-Options nosniff always;，always参数确保 304/204 等非 200 响应也带上 - Apache：用
Header set X-Content-Type-Options "nosniff" "expr=%{REQUEST_STATUS} == 200"不够稳妥；应改用Header always set X-Content-Type-Options "nosniff"，并确认mod_headers已启用 - 注意：IIS 默认不支持直接写这个 header，需通过
web.config的<httpProtocol>节点配置
它和 Content-Type 的配合要点
X-Content-Type-Options: nosniff 只在服务器返回的 Content-Type 存在且值不明确时起作用。例如：
- 返回
Content-Type: text/plain+nosniff→ 浏览器死守text/plain，哪怕文件内容是<script>alert(1)</script> - 返回
Content-Type: text/html→nosniff不触发，因为类型已明确 - 返回空
Content-Type或Content-Type: application/octet-stream→ 即使有nosniff，部分旧版 IE 仍可能 sniff（这是历史兼容性问题，无法靠该 header 彻底解决）
所以真正关键的是：所有可执行资源（JS/CSS）必须配对正确的 Content-Type，比如 application/javascript、text/css，再叠加上 nosniff 才算闭环。
