Godot 截图分享隐私检查：漂亮图片发出去之前先看有没有敏感信息

拍照模式和截图分享能带来传播，但它也可能把不该出现的信息一起发出去：玩家 UID、聊天内容、内部调试面板、未公开活动入口、服务器环境、坐标、队友昵称。截图一旦进入系统分享面板，客户端就很难收回。

Godot 里截图可以通过 Viewport texture、Image 保存或平台分享插件完成。真正需要设计的是分享前的隐私检查：哪些 UI 层要隐藏，哪些信息要打码，是否加水印，是否允许玩家预览和确认。

项目里的真实问题

一次内测中，玩家分享了一张漂亮的 Boss 截图，但右上角带着测试服地址和账号 UID。另一次截图里聊天窗口暴露了队友昵称和私聊内容。团队临时在拍照模式隐藏 HUD，但普通截图分享入口仍然可能捕获所有 UI。

隐私检查不能只依赖某个拍照页面。所有分享入口都应该经过 SharePrivacyGuard：拍照模式、结算分享、战绩图、客服反馈截图、系统截屏提示都至少要区分用途。

设计目标

• 敏感层可识别：UID、聊天、调试、坐标和未公开入口有明确标记。
• 用途分级：玩家分享、客服反馈、内部 QA 截图使用不同遮罩策略。
• 预览确认：玩家分享前能看到最终图片，而不是直接发原始画面。
• 可追踪：水印和日志能标识版本，但不泄露敏感信息。

这些目标不是为了堆抽象，而是为了让 Godot 客户端在内容量增加、平台差异变多、团队协作变复杂之后仍然可维护。原型阶段直接在节点脚本里写判断很快，但进入发版节奏后，系统需要能解释当前状态、能处理失败、能被 QA 复现，也能被后续同事接手。

推荐架构

flowchart TD
    A["截图/分享请求"] --> B["SharePrivacyGuard"]
    B --> C["敏感层识别"]
    B --> D["遮罩策略"]
    B --> E["水印生成"]
    B --> F["分享确认"]
    C --> G["状态快照"]
    D --> G
    E --> G
    F --> G
    G --> H["UI反馈/日志/回滚"]

图里的模块可以按项目规模合并。小团队可以先用一个 Autoload 管理核心状态，大团队再拆成 Resource 配置、运行时服务、调试面板和 UI ViewModel。真正重要的是调用方向：场景和 UI 不直接修改底层状态，而是提交意图并订阅快照。

关键实现细节

UI 节点可以声明 privacy_tag，例如 public、personal、debug、chat、internal、support_only。截图前 Guard 根据 share_purpose 决定隐藏、模糊、打码或保留。玩家分享应隐藏 personal 和 debug，客服反馈可以保留部分诊断但打码 token。
截图流程最好分两步：capture raw、apply privacy policy、show preview。预览图是最终会分享的图片，玩家确认后再调用平台分享。不要直接把 raw screenshot 交给系统。
聊天和昵称要谨慎。公开分享可以隐藏聊天层，战绩图可以显示玩家自己的昵称但隐藏 UID，队友昵称是否显示要看社交规则。隐私策略要由产品确认，不应程序临时判断。
水印可以包含游戏版本、资源版本和渠道，但不应包含完整账号、服务器 IP 或内部环境名。内测包可以加明显测试水印，正式包水印更克制。

失败处理和恢复路径

某个 UI 节点没有 privacy_tag 时，默认按保守策略处理，至少开发包报警。
隐私处理失败时，玩家分享应阻断并提示截图生成失败；客服反馈可以提示重新截图。
平台分享取消不应删除本地原始诊断图，若是客服反馈用途，需要按策略保存到 user://reports。

数据契约和协作接口

ShareRequest 包含 purpose、include_ui、watermark_profile、privacy_policy。
UI 根节点或 CanvasLayer 声明 privacy_tag，Guard 统一处理。
分享插件只接收处理后的 image_path，不接触 raw screenshot。

GDScript 接口草图

class_name SharePrivacyGuard
extends Node

signal snapshot_changed(snapshot: Dictionary)
signal warning_raised(code: String, detail: Dictionary)

var _snapshot := {}
var _active_version := 0

func submit(intent: Dictionary) -> void:
    _active_version += 1
    var version := _active_version
    _snapshot = {"phase": "pending", "intent": intent, "system": "godot-screenshot-share-privacy-review-2026"}
    emit_signal("snapshot_changed", _snapshot)
    _resolve(intent, func(result: Dictionary):
        if version != _active_version:
            return
        if result.get("warning", "") != "":
            emit_signal("warning_raised", result.warning, result)
        _snapshot = result
        emit_signal("snapshot_changed", _snapshot)
    )

func current_snapshot() -> Dictionary:
    return _snapshot.duplicate(true)

接口草图展示的是系统边界，不是完整实现。真实项目里还要补超时、取消、错误码、日志字段和平台差异。保留版本号，是为了避免旧异步结果覆盖新状态。

分阶段落地

第一阶段接入拍照模式和结算分享，隐藏 debug、UID、聊天层。
第二阶段加入 privacy_tag 扫描、预览确认和水印配置。
第三阶段区分客服反馈、内部 QA、玩家公开分享三类策略。

自动化验证和人工验收

打开调试面板、聊天、UID 后截图分享，最终预览不含敏感信息。
客服反馈截图保留必要版本信息，但敏感账号字段打码。
未标记 UI 节点在开发包报警。
平台分享取消后，状态和临时文件清理正确。

观测指标

• 分享请求数量、取消率和失败原因。
• 未标记隐私节点数量。
• 隐私处理耗时和图片大小。
• 客服反馈中截图可用率。

指标不一定全部进入正式服。开发包可以显示完整调试面板，内测包采样关键计数，正式包只保留错误码和聚合趋势。指标的目的不是制造报表，而是让一次异常能被定位到具体阶段、具体配置和具体玩家路径。

上线前检查清单

• 所有截图分享入口经过 SharePrivacyGuard。
• UI 层有 privacy_tag 或默认保守策略。
• 玩家分享前显示处理后预览。
• 水印不包含敏感账号或内部地址。
• raw screenshot 不直接交给平台分享。

检查清单不是为了增加流程负担，而是把隐性经验写下来。能自动化的尽量交给脚本，不能自动化的也要明确谁在什么阶段确认。

案例复盘

一次测试服截图泄露了内部 API 域名，原因是 debug overlay 属于普通 CanvasLayer，没有被拍照模式隐藏。引入 privacy_tag 后，debug 层标记为 internal，玩家分享策略会自动隐藏。即使未来新增调试面板，也能通过扫描发现未标记节点。

灰度验收脚本

灰度验收可以准备四张截图场景：普通 HUD、聊天打开、调试信息打开、战绩结算。分别走玩家分享和客服反馈策略，对比输出图片。验收重点是最终预览，不是 raw 画面。

维护策略

截图分享上线后，新增 UI 层必须声明 privacy_tag。UI PR 模板里可以加一项“截图分享策略”。活动和运营入口也要注意未公开信息是否可能进入分享图。

工程补充

隐私策略还要覆盖水印位置。水印不能遮挡玩家想分享的主体，也不能放在容易被裁掉的位置。内测水印可以更明显，正式分享水印应克制。若图片用于客服反馈，水印可以包含更多诊断摘要；若用于公开分享，则只保留版本或活动标识。

这个系统落地后，配置版本要进入日志和问题反馈。无论是停顿规则、地表定义、高亮样式、配方表、成就定义还是占位策略，只要配置能影响玩家体验，就应该有版本号。线上反馈如果只知道“高亮不对”或“脚步声错了”，但不知道玩家用的是哪版配置，排查会非常慢。

调试面板也要尽早准备。开发包里至少能看到当前输入意图、系统决策、最终快照、失败原因和配置来源。对于表现类系统，最好能在画面上叠加当前 id：surface_id、highlight source、recipe_id、achievement_id、boss_phase。QA 截图带上这些信息，开发就能少猜很多。

协作与内容接入

这类系统大多需要内容同学持续接入。新增地表、新增配方、新增成就、新增 Boss 阶段、新增高亮样式，都不应该只改一个资源路径。每种新增内容都要有最小样本和验收步骤。样本可以很小，但必须能触发主要路径和失败路径。

建议把接入说明写成三段：需要填哪些字段，常见错误是什么，如何在调试模式验证。文档不必冗长，但要足够具体。例如“新增配方必须提供 recipe_version、result_preview、server_quote_policy”，比“记得配置完整”有用得多。

边界和降级

降级策略要提前写清楚。HitStop 异常时可以跳过停顿但保留伤害；脚步 Surface 缺失时用默认脚步；高亮样式缺失时用低强度默认描边；制作 quote 失败时禁用制作按钮；成就平台同步失败时保留本地 pending；截图隐私处理失败时阻断公开分享。不同系统的降级不一样，不能统一成“出错请重试”。

降级也要进入指标。fallback 次数长期偏高，说明内容或配置质量有问题。运行时兜底是保护玩家路径，不是让错误长期存在。每周看一次 fallback 排行，比发版前临时大扫除更有效。

灰度补充

灰度验收还要覆盖平台分享失败。玩家确认分享后，系统分享面板可能取消、失败或没有可用应用。客户端应回到预览页或关闭流程，并清理临时文件。不能因为分享失败把 raw screenshot 留在公开目录。

如果项目支持相册保存，保存到相册和分享到社交平台应使用同一张隐私处理后的图片。不要出现分享图已打码、相册图未打码的分叉路径。所有对外流出的图片都必须经过同一套 Guard。

交付补充

还要注意临时文件生命周期。分享预览图如果保存在 user://，确认分享或取消后都应进入清理队列。客服反馈用途可以保留，公开分享用途不应长期保存。

小团队接入版本

小团队可以先做最简单的层级隐藏：分享前隐藏 DebugLayer、ChatLayer、AccountInfoLayer。即使没有模糊和智能打码，也比直接分享全画面安全。

交付边界

交付标准是玩家分享的图好看且不泄露敏感信息，客服反馈图保留足够诊断信息。隐私检查不是阻碍分享，而是让分享可以放心开放。

结语

截图分享越方便，越需要边界。Godot 客户端把分享入口统一到隐私检查流程后，漂亮图片可以发出去，敏感信息也能留在客户端里。