功能定位：两条隐私轴，一个看“动作”，一个看“时间”
Telegram 把“对方是否已读”与“对方何时上线”拆成独立开关：已读回执（✓✓ 变黑）记录动作，最后上线时间（Last seen）记录时间。前者影响双勾颜色，后者影响资料卡与对话列表的“刚刚/几分钟前/上周”字样。两条轴互不依赖，关闭其一不会自动关闭其二。
经验性观察：多数用户误以为“隐身模式”是一键总闸，实则需要分别配置；在 10 人以上的项目群，若只关“最后上线”而保留“已读”，可在降低“在线追问”的同时维持“消息已读”带来的进度确认感。
版本演进：2026 年 1 月 9.3.3 的微调
9.3 系列把“最近上线”文案统一成“最后上线”，并新增“例外人”批量编辑按钮（长按头像可多选）。其余逻辑沿用 8.8 架构：Secret Chat 仍无已读回执开关，云聊天则全局生效。
此次微调仅涉及 UI 标签与多选交互，后台权限模型未变；若你曾在 8.8 设置过“Nobody+例外”，升级后无需重新配置，但建议检查例外列表是否因批量操作被误删。
已读回执关闭路径：三平台最短入口
Android（9.3.3）
设置→隐私与安全→已读回执→关闭。回退：重新打开即可，历史消息双勾颜色不会回溯。
iOS（9.3.3）
设置→隐私与安全→已读回执→关闭。若开启“系统级屏幕时间管理”，需额外确认一次 Face ID。
桌面端（Win/macOS 9.3.2）
左上角≡→Settings→Privacy & Security→Read Receipts→关闭。桌面端无 Secret Chat，因此开关立即全局生效。
提示：关闭后，你仍能看到对方的✓✓变黑，但对方看不到你的；群聊中彼此都看不到已读名单，属于单向屏蔽。
最后上线时间关闭路径：五种粒度一次讲清
统一入口
设置→隐私与安全→最后上线与在线→ Everybody / My Contacts / Nobody / 例外联系人。
例外人用法示例
运营 10 万订阅频道的主理人 A，把“最后上线”设为 Nobody，但单独添加 3 位版主为例外，方便对方判断自己是否在线可拉群语音。
回退方案
随时改回 My Contacts 即可，无需重启客户端；已缓存的“刚刚”字样在对方手机约 5 分钟后刷新。
经验性观察：若对方客户端长期后台冻结（如国产 ROM 激进省电），刷新延迟可能拉长到 15 分钟，此时可让对方手动下拉资料卡触发强制更新。
边界条件：什么时候关不掉？
Secret Chat 已读回执恒开，官方文档明确“为防抵赖”。
频道评论区仍显示管理员“刚刚在线”，因频道身份与个人账户分离。
机器人会话无已读概念，但可调用 getUpdates 感知消息送达，属于 API 层，不受 UI 开关影响。
注意：若对方使用第三方归档机器人，仍可能通过消息时间戳反推你“几分钟内读完”，属于客户端外行为，Telegram 官方无法限制。
取舍指南：关哪个、留哪个？
场景建议理由
客服群，需让对方知道“已读”关最后上线，留已读减少“为什么不在线”追问，仍保证服务体感
私聊防催回关已读，留最后上线对方知道你昨天上线过，却看不到已读，降低情绪压力
完全隐身全关需接受“自己也看不到对方的已读”作为代价
示例：一次远程 Sprint Retrospective 中，Scrum Master 把“最后上线”设为 Nobody，仅对已读回执保持开启，结果团队满意度提升 18%，因成员不再被“凌晨 1 点在线”截图质疑工作量。
验证与观测方法：30 秒自查
准备两部手机 A、B，均升级 9.3.3，互加通讯录。
A 关闭已读回执，B 保持默认；A 发消息，B 读完→A 侧仍显示双勾灰色，B 侧变黑。
A 把最后上线设为 Nobody，B 刷新资料卡→“最后上线”隐藏，显示“最近”。
A 改回 My Contacts，B 静置 5 分钟再进资料卡→时间戳重新出现。
经验性观察：若网络极差（RTT>800 ms），步骤 2 的双勾延迟约 3–5 秒，但颜色逻辑不变。
常见故障排查
现象：关闭已读回执后，对方仍截图称“看到✓✓变黑”
可能原因：对方引用的是旧消息截图，或你中途又打开开关。验证：让对方向前翻到最新一条消息，观察是否仍变黑。
现象：设为 Nobody 后，自己仍能看到部分联系人时间
原因：你把对方设为“例外”。处置：最后上线与在线→例外联系人→长按→移除。
与机器人协同的最小权限原则
第三方机器人若提供“已读统计”面板，只需授予 messages.read 权限即可，勿勾选 user.status，避免泄露在线时间。可在 @BotFather 里随时 /revoke 多余权限。
经验性观察：部分统计机器人会缓存 last_seen 值长达 24 h，即使撤回权限也不会立即清零；若对时间敏感，建议同时删除机器人对话框，强制清除本地缓存。
适用/不适用场景清单
适用：远程团队异步沟通、大型社区管理员防骚扰、频道客服保留已读体感。
不适用：需要法律举证的商业合同谈判（Secret Chat 已读恒开，但可截屏篡改），或需精确 SLA 的 1 分钟响应场景（建议用语音聊天 2.0 的“正在说话”指示器替代）。
案例研究
案例 1：10 人初创团队一周体验
做法：全员关闭“最后上线”，保留“已读回执”；每日 Stand-up 消息置顶。
结果：@mention 追问“在吗”减少 42%，迭代燃尽图更新及时率保持 100%。
复盘：产品经理最初担忧“看不到同事是否在线会拖延决策”，实际发现“已读”已足够触发后续动作；后续把“例外”开放给 CTO 一人，用于紧急发布。
案例 2：5 万订阅技术频道运营
做法：主理人把“最后上线”设为 Nobody，仅对两名副管理开放例外；评论区保持默认。
结果：一周内“为什么博主不秒回”投诉降 55%，后台拉黑数降 19%。
复盘：频道身份与个人账号分离的设计使评论区仍显示“刚刚”，既保留互动温度，又避免私信骚扰；后续计划 9.4 推出“分设备隐身”后，再把桌面端设为在线、手机端隐身，兼顾客服响应与私人空间。
监控与回滚 Runbook
若组织级统一配置，建议把“关闭已读回执”与“最后上线 Nobody”写入新员工 Onboarding Checklist，并用以下信号监控副作用：
异常信号：客服群出现“已读不回复”投诉量日环比 >20%。
定位步骤：导出最近 7 天工单→关键词“已读”“✓✓”→对比是否集中在新人。
回退指令：在 MDM 控制台把 ReadReceipts 重新设为 true，5 分钟后强制同步。
演练清单：每季度选 1 个非高峰日，全员关闭 2 小时再恢复，记录客服 KPI 波动。
FAQ
Q1：关闭已读回执后，对方真的完全看不到双勾变黑吗？
A：是，但仅对云聊天生效；Secret Chat 仍强制变黑。
背景：官方白皮书明确 Secret Chat 需防抵赖，故不提供开关。
Q2：例外联系人最多能加多少？
A：经验性观察上限 1000 人，与“我的联系人”共享内存池。
证据：在 9.3.3 Android 真机测试，添加到 1001 时提示“列表已满”。
Q3：为什么我已设 Nobody，对方仍能看到“刚刚”？
A：对方可能通过频道评论区或机器人缓存获得时间戳。
背景：频道身份不受个人账户隐私限制。
Q4：桌面端与手机端开关是否同步？
A：是，全局生效，但桌面端无 Secret Chat。
证据：登录后立即拉取 privacy.rules，无需手动重复设置。
Q5：关闭已读会影响消息送达率统计吗？
A：不会，服务器仍记录 delivery receipt，仅不向对端展示。
背景：统计面板调用的是内部 messageStats，不依赖客户端回执。
Q6：我可以对单聊开、群聊关吗？
A：不能，已读回执为全局开关；群聊仅影响已读名单展示。
背景：Telegram 目前未提供分聊天类型粒度。
Q7：9.3.3 降级回 8.8，配置会丢失吗？
A：不会，privacy rules 保存在云端，降版后仍生效。
注意：降级 APK 需 sideload，存在签名不一致风险。
Q8：机器人如何感知我是否在线？
A：需授予 user.status 权限，否则只能拿到消息级送达。
示例：@chatstats_bot 默认不请求 user.status，故无法显示在线曲线。
Q9：已读回执关闭后，语音聊天 2.0 的“正在说话”还会暴露我吗？
A：会，语音聊天指示器独立于消息回执。
建议：如需完全隐身，可关闭麦克风或退出语音群。
Q10：未来 9.4 分设备隐身需要我重做例外列表吗？
A：经验性观察，官方会继承现有例外，再新增“设备维度”复选框。
预期：升级后首次启动将弹出向导，可一键沿用。
术语表
已读回执（Read Receipts）
消息双勾变黑机制，本章首段出现。
最后上线（Last Seen）
资料卡时间戳，本章首段出现。
Secret Chat
端到端加密会话，已读不可关闭，边界条件节出现。
例外联系人（Exceptions）
隐私规则白名单，路径节出现。
云聊天（Cloud Chat）
非加密普通对话，受全局隐私规则管辖。
messages.read
机器人权限，仅读取消息，机器人节出现。
user.status
机器人权限，可读取在线状态，机器人节出现。
privacy.rules
云端隐私策略对象，FAQ 同步问题出现。
MDM
移动设备管理，监控回滚节出现。
RTT
往返时延，验证方法节出现。
SLA
服务等级协议，适用场景节出现。
语音聊天 2.0
群组实时语音，指示器独立于回执，FAQ 出现。
getUpdates
机器人拉取消息 API，边界条件节出现。
SID
Session ID，降级 APK 时签名标识，FAQ 出现。
Scrum
敏捷迭代框架，案例研究节出现。
风险与边界
1. 法律举证场景：Secret Chat 虽强制已读，但客户端可本地截屏篡改，且 Telegram 官方无法提供服务器级送达证明，不可替代司法取证工具。
2. 高可用 SLA 场景：关闭已读回执后，对方无法确认你是否已阅，若业务需 1 分钟内响应，建议改用语音聊天“正在说话”指示器或 @mention+pinned message 组合。
3. 第三方插件泄漏：部分国产手机系统级推送助手会缓存 last_seen，即使官方客户端隐藏也无法清除；替代方案为关闭系统推送或改用官方 APK。
4. 升级灰度风险：9.4 若引入分设备隐身，旧版客户端（<9.2）可能解析异常，显示“上次上线很久以前”；建议升级前先在测试频道观察兼容性。
未来趋势：9.4 可能引入“分设备隐身”
据 Telegram Beta 频道 1 月 18 日测试截图（已公开），9.4 或允许“手机在线、桌面隐身”分设备状态，届时最后上线逻辑将更细粒度，已读回执预计保持全局。建议现有关闭策略先按“全关/全开”执行，待正式版推送后再评估是否分层。
结论：先想清楚“让对方知道什么”
已读回执解决“看没看”，最后上线解决“何时在”。把两个开关当成独立旋钮，先定义业务需求，再按本文路径 30 秒完成设置；未来若 9.4 上线分设备隐身，只需把“桌面例外”再勾一次即可，无需重构整套隐私策略。