用语义化 标签分层表达积分规则： 写动作（如“发布原创帖”）， 写分值与条件，数值和运算符用 包裹，前提单独成句，每条规则设唯一 id 便于动态更新，禁用模糊表述与伪公式。
HTML里怎么写清楚“积分怎么算”这种业务规则
直接用语义化标签把计算逻辑分层表达，别堆在 <div> 里硬塞文字。用户不是来读代码的，是来确认“我发一条评论到底加几分”的。<p>常见错误是把公式写成纯文本段落：<code>“点赞×2 + 评论×5 + 分享×10”，没说明前提、边界和例外。更糟的是混在样式类名里，比如 class="score-rule-3"，谁也猜不出规则是什么。
- 用
<dl></dl>（定义列表）组织规则项：每个<dt></dt>写动作（如“发布原创帖”），<dd></dd>写对应分值和条件 - 数值和运算符必须用
<code>包裹，比如+5、×2、上限100分/天 - 有前提条件就单独成句，比如
仅限首次发布或需通过审核后生效，别缩写成“首发+5”
怎么处理动态变化的积分规则（比如运营活动期间翻倍）
静态 HTML 本身不执行逻辑，但得为后续 JS 或服务端渲染留出明确锚点。关键是让规则变更时，前端能精准定位并替换某条规则，而不是整块重绘。
错误做法是把所有规则塞进一个 <p></p>，改个系数就得全文本查找替换；或者用注释写“活动期×2”，但没人保证注释和实际展示同步。
立即学习“前端免费学习笔记（深入）”；
- 每条规则外层加唯一
id，比如id="rule-post-original"，方便 JS 按 ID 更新 - 系数类数字单独包裹
<span class="score-value">5</span>，CSS 加data-activity="true"属性标记活动状态 - 避免在 HTML 里写 JavaScript 表达式，比如
score = likes * 2—— 这属于运行时逻辑，不该出现在页面源码中
为什么不能用 <table> 列积分规则<p>表格适合行列关系明确的结构化数据，但积分规则本质是“动作→结果+条件”的映射，不是二维矩阵。强行用表会带来三个实际问题：</p>
<ul>
<li>屏幕阅读器把每行当独立数据行读，用户听到“点赞，2分，无限制”三遍，中间没停顿，理解成本高</li>
<li>移动端窄屏下表格横向溢出，用户要左右拖才能看全“条件”列</li>
<li>后续加新规则（比如“绑定手机号+10分”）时，要同时改 <code><thead> 和所有 <code><tr>，易漏掉某处<p>真要用表格，至少把条件合并进同一单元格，比如 <code><td>点赞<br><code>+2（每日上限5次），但不如 <dl></dl> 清晰。
要不要把公式写成 MathML 或 KaTeX 渲染
没必要。99% 的积分规则是线性加减乘，比如 基础分 + 等级系数 × 行为分，用普通文本 + <code> 已足够准确。上 MathML 反而增加加载负担，且多数 CMS 不支持。
真正该警惕的是“伪公式”：把业务逻辑藏在模糊表述里，比如 “活跃度加成”、“综合评估后发放” —— 这种词等于没说，用户无法预期结果，客服压力直接翻倍。
复杂点在于“条件嵌套”，比如“连续签到第7天额外+20，但中断后重置”。这种必须拆成两句话，用 <strong></strong> 标出关键触发词，比如 <strong>连续</strong>签到第7天、<strong>中断即重置</strong>。否则人眼扫过去根本注意不到那个“连续”。
