先记住这个答案
<meta http-equiv> 只能实现规范认可的少数文档级指令，浏览器读到它时文档解析已经开始，因此不等同真正的 HTTP 响应头。例如 CSP 若需要在资源加载前生效，更适合由服务器发送；缓存和跨源控制也不能随意写成 meta 标签。先问这个策略需要在什么时刻生效，再选放置位置。
http-equiv只识别特定值- meta CSP 能力有限
- 缓存应使用 HTTP 响应头
- pragma 生效晚于响应头
安全策略不能只靠页面 meta
团队想在页面里写 <meta http-equiv="content-security-policy"> 阻止资源加载。这种写法可提供部分 CSP 约束，但不能像响应头那样覆盖所有指令，且在浏览器解析到它之前已处理的内容无法被追溯。若要设置 frame-ancestors 之类策略，就必须用 HTTP 头。把 <meta http-equiv="cache-control"> 当成可靠缓存控制尤其危险，浏览器缓存行为应从响应头和资源 URL 设计。
<head>
<meta charset="UTF-8">
<meta http-equiv="content-security-policy"
content="default-src 'self'">
<meta http-equiv="refresh" content="30">
</head>
<!-- 关键安全策略仍优先放 HTTP 响应头 -->http-equiv 名字像 HTTP 头，但标准只为特定值定义处理模型。
示例同时放了 CSP 与 30 秒刷新指令，正好展示它们虽都写成 http-equiv，用途却完全不同。真实安全策略不宜照抄这个小片段：若页面用第三方脚本、字体或图片，default-src 'self' 可能把资源挡住；刷新也会打断用户。代码只是语法展示，业务页面应分别制定允许来源、跳转必要性和服务器响应头配置。
pragma 不等同响应头
CSP meta 可以施加部分策略，却不能使用某些只适合响应头的指令；refresh 会触发延时刷新或跳转，但有可用性风险。即使名称相似，pragma 的生效时间与处理规则也可能不同于真实响应头。服务器返回时就需要确定的缓存、嵌入限制和跨域政策，不应靠页面内部元数据模拟。
一个具体边界是 CSP：写在 meta 中的策略要等浏览器解析到该元素才能生效，且部分指令不被这种方式支持。若页面前面已经加载了脚本，后面的 meta 无法追溯阻止它。需要统一约束整个响应及早期资源时，应在服务器响应头发送策略，并在浏览器开发工具里查看实际生效的头与违规报告。
旧项目中可能出现 <meta http-equiv="X-UA-Compatible"> 之类历史兼容写法。迁移到现代浏览器时，不能把它理解成任何自定义响应头都能等价搬进 HTML；可识别的值由规范和浏览器实现限定。项目若需要安全策略、缓存或内容类型，先在 Network 面板看服务器实际响应，再核对浏览器支持的机制。
容易答错的地方
- 以为所有响应头都能写成 meta
- 浏览器只识别定义过的 pragma，任意名字不会变成有效 HTTP 头。
- 把 CSP meta 当成响应头等价物
- 它不能表达全部 CSP 能力，生效时机也更晚。
面试官还会怎么问？
frame-ancestors 能放进 CSP meta 吗？
不能。防止被嵌入的策略应由 HTTP 响应头发送。
缓存能靠 meta cache-control 禁止吗？
不能把它当成可靠方案，应通过真实缓存响应头控制。
refresh 是不是也可以当作路由跳转？
技术上可定时跳转，但普通导航更适合使用链接或服务端重定向。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。