HTML无法计算阅读时间，必须由JavaScript实现；reading-time库需适配中文、清理HTML标签、单独计算图片时间，并延迟至内容渲染完成后再调用；localStorage存滚动位置比存预测时间更可靠；服务端预估静态但快，客户端可实时动态调整。
HTML 本身不能计算文章预计阅读时间，所有“估算”逻辑必须由 JavaScript 承担。直接在 <time> 或 <meta> 里硬写 content="5 min" 是静态值，不是估算——它不会随用户行为、内容更新或阅读习惯变化。
reading-time 库怎么用才不翻车
最常用的是 npm 包 reading-time，但它默认只按词数除以 200（WPM）算，对技术文档、带代码块或大量图片的文章偏差明显。
- 中文内容要显式传
wordBound: /[\u4e00-\u9fa5]+/g，否则会把整段当一个“词” - 含 HTML 的文章必须先用
DOMParser或正则清理标签，否则<pre>console.log(123)</pre>里的代码会被当作文本计入字数 - 图片时间要单独加：用
document.querySelectorAll('img').length获取数量，再按“首图 12 秒，次图 11 秒…第 10 图起每张 3 秒”累加，最后合并到readingTime()结果的time字段上 - 别在
DOMContentLoaded立刻调用——等article元素真实渲染完（可用requestIdleCallback或MutationObserver监听内容插入）
为什么 localStorage 存滚动位置比存“预测时间”更可靠
用户关闭页面时，beforeunload 不一定触发（比如崩溃、杀进程、PWA 后台冻结），导致你存的“当前预测值”永远滞后。而滚动位置是离散、低频、可验证的：
- 每次
scroll后节流 300ms，只存window.scrollY到localStorage.setItem('lastScroll', scrollY) - 页面加载后立即
scrollTo(0, +localStorage.getItem('lastScroll') || 0)，比任何模型都快且稳定 - 如果非要显示预测，只在用户已停留 >30 秒 + 滚动过至少两屏后才启动计算，避免首页刚打开就报“预计还需 47 分钟”这种反效果文案
服务端预估（如 Hugo）和客户端实时估算的区别在哪
Hugo 的 .ReadingTime 是构建时一次性算的：取原文纯文本字数 ÷ 200，结果写死进 HTML。它快、无 JS 依赖，但无法反映用户实际阅读节奏。
立即学习“前端免费学习笔记（深入）”；
- 服务端预估适合静态博客，但改速难——想调成 250 WPM？得改模板里
.ReadingTime * 200 / 250再四舍五入 - 客户端实时估算能结合
performance.now()和滚动位移算出像素/毫秒速度，再映射到剩余内容高度，更适合教程、课程页这类需要进度感知的场景 - 混合方案最稳：服务端提供基础值（如
data-estimated-time="4"），客户端用它做 fallback，有行为数据后再覆盖显示
真正容易被忽略的不是算法多复杂，而是“预测”二字带来的心理预期——用户看到“约 6 分钟”，潜意识已接受误差 ±2 分钟；但如果你返回“6.3 分钟”，他就会盯着那个 .3 看，怀疑你是不是卡住了。
