closedloop-spec

功能名称：基于用户反馈的只读模式增强 1. 背景与目标 根据客户在支持工单（见 support-ticket-2023-Q4-0872）和产品论坛（forum.google.com/thread/feature-request-read-only-mode）中的反馈，用户频繁请求在查看共享文档时避免意外修改内容。现有代码库中已存在只读视图的实现（参见 /src/components/DocumentViewer/ReadOnlyRenderer.js），但该组件未集成到主导航流程中，且缺乏状态持久化能力。本设计旨在扩展现有只读基础设施，提供一致、可预测的只读体验，所有变更均为读取操作，不写入数据或修改后端状态。 2. 用户需求与证据 - 用户陈述：“我经常打开同事分享的文档，只想看内容，但总不小心点了编辑按钮。”（support-ticket-2023-Q4-0872） - 用户陈述：“希望有一个明确的‘仅查看’入口，让我知道我不会改任何东西。”（forum.google.com/thread/feature-request-read-only-mode） - 使用模式分析显示，78% 的共享链接访问来自非所有者用户（见 analytics/shared-link-access-report-2023.csv），表明只读场景占主导。 3. 设计决策 3.1 新增只读模式入口 在文档顶部导航栏添加“仅查看”按钮，点击后进入只读模式。 依据：现有导航组件支持动态按钮注入（参见 /src/components/TopNav/DynamicActionButton.js），该组件已在“打印”和“导出”功能中使用，遵循相同模式可确保一致性。 3.2 状态持久化 用户进入只读模式后，状态通过 URL 参数 ?mode=readonly 持久化，刷新页面后仍保持只读状态。 依据：当前 URL 参数处理逻辑位于 /src/utils/urlStateManager.js，已用于管理 ?tab=comments 等状态，复用该机制可避免重复造轮子。 3.3 禁用编辑控件 在只读模式下，隐藏或禁用所有编辑相关 UI 元素（如工具栏编辑按钮、右键菜单中的“编辑”选项）。 依据：ReadOnlyRenderer.js 已实现控件屏蔽逻辑（第 45–62 行），可直接复用其条件渲染策略。 3.4 视觉提示 在只读模式下，顶部导航栏显示灰色徽章“仅查看”，并提供退出链接。 依据：现有通知系统使用 Badge 组件（/src/components/UI/Badge.js），已在“离线模式”中使用相同样式，确保视觉一致性。 3.5 无数据写入保证 所有交互（包括滚动、缩放、评论展开）均通过只读 API 端点获取数据（参见 /api/v1/documents/{id}/readonly），不触发任何 PATCH 或 POST 请求。 依据：后端已有只读接口实现（backend/routes/documentReadonly.js），前端仅需路由至该端点，符合现有安全边界。 4. 非目标 - 不支持在只读模式下添加注释或高亮（需写权限，违反只读原则）。 - 不修改现有编辑流程或权限模型。 5. 成功指标 - 只读模式入口点击率 > 40%（基线：当前无显式入口，点击率为 0）。 - 用户在只读模式下触发编辑操作的误触率下降至 < 2%（当前为 11%，见 usability-test-report-2023.pdf）。 6. 风险与缓解 - 风险：URL 参数可能被手动删除导致状态丢失。 缓解：在进入只读模式时同步更新浏览器历史状态（使用 history.replaceState），参考 /src/utils/historyManager.js 中的实现。 - 风险：第三方嵌入场景下无法控制父页面 URL。 缓解：在嵌入 iframe 中检测 parent.location 不可写时，改用 localStorage 存储模式状态（参见 /src/storage/sessionStore.js 的跨域安全策略）。 本设计完全基于现有代码模式和真实用户反馈，所有决策均有文件或数据支撑，确保可实施性与一致性。

存档时间线

版本索引永久保留；内容副本只保留最新 1 份，更早版本仅留索引与哈希（存档时间线的证据链不会因此断裂）。

下载存档内容副本