2) 在页面加载前手动在地址栏加上锚点 #c123 并回车

• 页面加载完成后，没有自动滚动到该锚点，因为锚点对应的 DOM 节点并不存在（还未被 JS 渲染）。

3) 观察网络请求与渲染顺序

• 页面在初始渲染后发起评论数据请求（通常是 /api/comments?post=xxx）。
• JS 在收到数据后动态构建每条评论的元素并插入 DOM，此时才出现 id 或 data-comment-id。
• 浏览器的锚点定位只在文档初次加载完成时自动触发一次，动态插入的锚点不会触发浏览器回滚（除非脚本主动执行 scrollIntoView）。

4) 验证浏览器控制台能否通过脚本跳转

• 在 DevTools 执行 document.getElementById('c123').scrollIntoView() 可以正确定位到评论，说明评论本身存在且可滚动，只是没有自动触发。

结论（简明扼要） 根源：91在线当前的评论区采取的是“客户端渲染 + 异步加载评论”的策略，导致页面首次加载时并没有评论节点，浏览器的默认锚点行为不能实现对动态插入元素的跳转，因此直接分享带锚点的链接在未等待评论加载的情况下不会生效。

影响面：

• 用户分享单条评论的体验受损（接收者不会直接看到目标评论）；
• 社交平台抓取或搜索引擎命中带锚点的深链时，预览或直接跳转可能失效；
• 对需要引用评论记录（举证、取证、讨论）的用户非常不友好。

临时用户侧解决办法（当下可用） 如果你只是想分享或打开某条评论，下面几种方式可以用：

• 在同一台设备上复制链接后“等待评论加载”再打开：把链接粘到新标签页后稍等 1–2 秒，等评论加载完成，浏览器通常会有 JS 自动滚回（若没有，可F5再试）。
• 手动使用页面内的复制按钮（如果有）复制带有后端生成的分享链接：很多平台会在评论时间上绑定一个“分享”功能，生成带参数的深链（例如 ?comment_id=123），这类链接通常后端会处理，打开后会触发滚动。
• 如果能访问开发者控制台（高级用户）：打开页面后运行 scrollIntoView 的脚本（document.getElementById('c123').scrollIntoView()），能定位目标评论。
• 截图或使用页面内引用功能：当目标是留证据或引用，可用截图或导出评论内容（避免依赖锚链）。

建议（给站方和关心改善体验的你） 如果你是站方或有渠道反馈给产品/技术团队，以下修改能从根本上修复体验：

• 服务端渲染锚点（最佳）：在服务器端渲染初始 HTML 时包含评论锚点或至少包含目标注记。这样浏览器能在第一次加载时就滚动到位置，利于 SEO 和分享。
• 在客户端渲染流程中加入“锚点检测与回滚”逻辑：页面加载后检查 URL 是否含锚点或 comment_id 参数，等评论渲染完毕后调用 scrollIntoView 或平滑滚动到目标位置。
• 支持带参数的深链（例如 /post/123?comment_id=456）并在后端记录或在前端将参数映射为渲染后回滚。
• 为评论生成短链或分享链接（由后端生成可持久访问的 permalink），避免直接依赖 DOM 锚点。

我做了什么（我的动作与证明） 我在多个帖子、多个浏览器（Chrome/Firefox/无痕模式）上复现了问题，抓取了网络请求并验证了加载顺序，确认这是典型的“客户端异步渲染导致锚点失效”问题。实验中我演示了如何用脚本手动滚动以及用 query 参数触发滚动（如果站点支持该参数）。

收尾与后续 这次“瓜”乍一看不刺激，但对日常使用与信息传递体验实际上挺关键。知道原因后，你可以按上面的临时办法来应急，或者把建议反馈给站方，让他们做一个稳妥的修复。后续我可以继续跟进：如果你愿意，我会抽时间写一份给产品/技术团队的简短需求文档模板，便于他们直接复用和开发。