HTML无原生“精华”语义标签，加权依赖后端注入data-属性（如data-essence="true"）并由前端JS/CSS消费，首屏直出确保稳定性与SEO，ARIA仅用于无障碍，不参与权重逻辑。
HTML里没有原生的“精华”或“版主加权”语义标签
浏览器和搜索引擎不识别 class="jinghua"、data-weight="admin" 这类自定义属性作为权威信号。所谓“精华推荐人工干预”，本质是前端展示逻辑 + 后端业务标识的配合，不是靠某个 HTML 标签一贴就生效。
- 所有加权、置顶、高亮行为，都依赖 JS 渲染时读取数据字段（比如
is_essence或weight_level），再动态加 class 或插入徽章 - 直接在 HTML 里硬写
<span class="essence-badge">精华</span>只是视觉呈现，不带任何语义或权重含义 - 如果想让爬虫或辅助技术感知，得用 ARIA 或微数据（但实际社区系统几乎不用——因为没后端配合就是摆设）
用 data- 属性传递人工干预状态最稳妥
这是前后端协作的事实标准：后端在渲染 HTML 时，把运营/版主操作的结果以 data- 属性注入 DOM，前端 JS 或 CSS 拿它做条件判断。
- 推荐命名如：
data-essence="true"、data-weight="2"、data-reviewed-by="moderator" - 避免用
data-flag、data-type这种模糊名，后期维护时根本猜不出含义 - CSS 可直接挂钩：
[data-essence="true"] { border-left: 4px solid #ff6b35; } - JS 判断也直观：
if (el.dataset.essence === "true") { ... }—— 注意 dataset 会自动转小写、去横线，data-reviewed-by对应dataset.reviewedBy
别把 role 或 aria- 当加权开关用
role="alert" 或 aria-label="精华帖" 是给无障碍工具看的，不是给推荐算法或运营后台看的。滥用反而干扰屏幕阅读器体验。
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
-
aria-label改变的是语音播报内容，不影响页面排序或样式逻辑 -
role="section"或role="complementary"属于结构语义，跟“人工加权”无任何关系 - 真要兼顾可访问性，应该在加徽章的同时补一句视觉隐藏文本：
<span class="sr-only">本帖由版主标记为精华</span>
后端模板里控制输出比前端 JS 补救更可靠
用户刷新页面时，如果靠 JS 异步请求“哪些是精华”，再 patch DOM，会出现闪动、延迟、SEO 不收录等问题。关键标识必须随首屏 HTML 一起下发。
立即学习“前端免费学习笔记（深入）”；
- 模板中写：
<article data-essence="{{ post.is_essence|lower }}"></article>（Jinja）或<div data-weight="<%= post.weight %>">（EJS） <li>禁止在前端用 JS 遍历标题关键词、发布时间、点赞数来“猜”是否精华——规则变一次，全站 JS 就得重写</li> <li>如果用 SSR 框架（如 Next.js、Nuxt），确保 <code>getServerSideProps或asyncData已把is_essence字段注入初始 props
事情说清了就结束。真正卡住人的从来不是怎么写那个
data- 属性，而是后端有没有把“版主点过加精”这个动作，稳定、低延迟、无歧义地落到每条帖子的结构化字段里。
