navigation.entries()仅返回当前文档生命周期内由navigation api主动创建的条目，不包含初始加载、手动输入、跨域或刷新产生的历史记录。
Navigation API 的 entries() 方法根本不能访问完整浏览历史
直接说结论：navigation.entries() 返回的只是当前文档生命周期内由 Navigation API 主动管理的导航条目（NavigationHistoryEntry），**不包含页面加载前已存在的历史记录**，也**无法读取跨文档、跨域或用户手动输入/刷新产生的条目**。它不是 window.history 的替代品，更不是浏览器地址栏历史的镜像。
常见错误现象是调用 navigation.entries() 后只看到 1–2 个条目（比如初始加载 + 一次 navigate()），误以为 API 没生效或被拦截了——其实它工作正常，只是设计如此。
- 仅包含通过
navigation.navigate()、navigation.back()等 Navigation API 触发的条目 - 每个条目只保留当前会话中该文档上下文内生成的数据（
state、key、url），不保存原始 HTTP 状态、时间戳、referrer 等 - 页面刷新后，之前通过 API 添加的条目仍存在（因属于同一文档生命周期），但手动输入 URL 或点击外链跳转产生的条目不会进入该列表
为什么不能用 entries() 替代 window.history
window.history 本身也**不允许脚本读取完整历史条目内容**（出于隐私和安全限制），它的 length 只是粗略计数，state 仅暴露当前项，go()/back() 是单向控制接口。Navigation API 延续并强化了这一约束。
如果你真正需要“遍历历史”，必须明确场景：
- 想实现自定义前进/后退按钮？→ 直接用
navigation.canGoBack/navigation.canGoForward+navigate()控制，别碰entries()列表 - 想在 SPA 中还原路由状态？→ 把关键状态存进
navigation.currentEntry.state，并在navigate事件中读取，而非依赖历史列表 - 想调试当前有哪些 Navigation 条目？→ 可以遍历
navigation.entries()查看结构，但仅限于你主动创建的那些
示例：打印当前可枚举的 Navigation 条目（仅作调试）
console.log(navigation.entries().map(e => ({
url: e.url,
key: e.key,
state: e.state
})));
entries() 的实际可用场景和性能注意点
它唯一可靠的用途是：在单页应用中，配合 navigate() 和 currentEntry，构建可预测、可序列化的导航状态流。不是为了“查看历史”，而是为了“管理本次导航上下文中的状态快照”。
- 条目数量极少（通常 ≤ 5），无需担心性能；但频繁调用
entries()并遍历做深比较（如 diffstate）可能触发不必要的对象创建，应缓存或节流 -
entries()返回的是实时更新的Array，不是只读副本；但修改数组本身不影响历史，也不能通过它增删条目 - 兼容性上，目前仅 Chromium 117+（含 Edge）、Firefox 126+ 支持；Safari 尚未实现，需降级到
pushState/popstate
容易被忽略的关键限制
最常被忽略的一点：navigation.entries() **不包含当前文档首次加载时的 entry** —— 它从第一个由 Navigation API 显式触发的导航开始计数。也就是说，entries()[0] 通常是第一次 navigate() 后的状态，不是页面初始 URL 对应的条目。
另一个隐形坑：如果使用 navigate(url, { history: 'replace' })，新条目会替换当前 currentEntry，但旧条目仍保留在 entries() 列表中（除非超出最大保留数，目前规范未强制上限，各浏览器实现不同）。这意味着列表长度未必等于用户感知的“后退步数”。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
