name属性为外部系统提供结构化元数据标识符，决定meta标签被谁读、如何解析；主流合法值如description（影响搜索摘要）、author（署名信息）、viewport（浏览器特例），而name与http-equiv本质不同：前者声明数据类型，后者模拟http响应头。
name属性在标签中到底起什么作用
它不是用来定义网页名称的，也不是给浏览器看的“名字”，而是为其他系统（比如搜索引擎、社交平台、第三方解析工具）提供结构化元数据的标识符。浏览器本身不关心name值是什么，但name决定了这条<meta>会被谁读、怎么读。
常见合法的name值及其实际用途
不同name对应不同解析规则，用错就等于白写。主流支持的有：
-
description：被搜索引擎摘要展示，影响搜索结果点击率；内容需简洁，建议 50–160 字 -
keywords：已基本被主流搜索引擎忽略，仅部分内部 CMS 或旧系统可能参考 -
author：纯信息性字段，无标准化格式要求，但建议用邮箱或规范署名，如<meta name="author" content="dev@example.com"> -
viewport：⚠️注意：这不是语义型name，而是name属性被历史沿用的特例，实际由浏览器原生解析，和http-equiv平级使用 - 社交平台专用：
og:title、og:description等属于 Open Graph 协议，严格来说它们是property而非name，混用name会导致不被识别
name="xxx" 和 http-equiv="xxx" 的根本区别
这是最容易混淆的点：name是向外部服务“声明数据类型”，http-equiv是向浏览器“模拟 HTTP 响应头”。两者不能互换。
-
<meta name="robots" content="noindex">→ 告诉搜索引擎不要索引此页 -
<meta http-equiv="refresh" content="5;url=https://example.com">→ 浏览器执行跳转，等效于 HTTP 头Refresh: 5; url=... - 写成
<meta name="refresh" ...>完全无效，浏览器不会解析，爬虫也不会识别 - 同理，
name="content-type"是错误写法，正确应为http-equiv="content-type"（尽管现代 HTML5 更推荐用<meta charset="utf-8">）
自定义 name 值是否可行？有什么风险
语法上允许任意字符串，但只有被目标系统约定识别的name才有意义。随意命名等于写注释。
- 例如
<meta name="build-timestamp" content="202405211430">对构建系统或监控脚本有用，但前提是你的 JS 或后端主动读取并处理它 - 浏览器不会暴露这个值到 DOM API（
document.querySelector('meta[name="build-timestamp"]')可查，但不是标准接口） - 若用于 CSP、安全策略等场景，必须用标准字段（如
http-equiv="Content-Security-Policy"），name无法触发任何安全机制 - 多个同名
meta标签时，浏览器按文档顺序取第一个，后续被忽略 —— 这点常被动态注入脚本踩坑
真正关键的不是“能不能写”，而是“谁会读、怎么读、读了之后做什么”。很多团队加了一堆name却从不验证下游是否真在消费，最后成了 HTML 里的幽灵字段。
