【寻迹校园 HarmonyOS NEXT 实战 28】不交换手机号也能交接：固定校内交接点的隐私设计

【寻迹校园 HarmonyOS NEXT 实战 28】不交换手机号也能交接：固定校内交接点的隐私设计

这是“寻迹校园 HarmonyOS NEXT 实战”系列第 28 篇。本文结合HandoffLocation、HandoffService与HandoffPage的真实实现，说明为什么校园失物招领应优先使用固定地点 ID 和有限时间段，而不是收集手机号、宿舍门牌或自由文本地址。

上图为原创生成的安全交接插画，不是地图截图或应用截图。三类校园公共服务点通过稳定 ID 进入业务流程，手机号、宿舍门牌和私人住址被排除在数据模型之外。

一、认领通过不等于可以立即交换联系方式

失物信息相似只说明“值得继续核验”。如果系统在同意认领后立即公开双方手机号，错误申请、恶意申请或审核误判都会扩大骚扰和人身安全风险。

校园场景有一个天然优势：教学楼值班台、图书馆服务台、保卫处等公共位置通常比私人地址更适合作为交接点。

因此产品不必先问“双方手机号是什么”，而应该先问“哪个受控公共点、哪个有限时间段可以完成线下核验”。

二、固定地点比自由文本地址多了什么约束

自由文本允许输入“某宿舍 503”“东门外小巷”“我的手机号……”等高风险内容，也很难验证地点是否真实开放。

固定地点模型只包含：

exportclassHandoffLocation{id:string='';name:string='';openHours:string='';}

这里没有手机号、联系人、经纬度、宿舍号或任意备注。数据模型从源头限制了可收集内容。

三、当前演示配置了三个公共交接点

HandoffService内置三条演示配置：

稳定 ID	展示名称	开放时段
TEACHING_1	第一教学楼值班台	08:00–21:00
LIBRARY_1	图书馆一层服务台	08:30–21:30
SECURITY_EAST	东门保卫处失物招领点	全天开放

稳定 ID 用于持久化和判断，名称与开放时段用于展示。未来文案变化时，不应因为“图书馆一层服务台”改名就破坏历史记录关联。

四、为什么返回地点列表时要复制对象

getLocations()不直接暴露内部数组，而是创建新的HandoffLocation：

getLocations():HandoffLocation[]{returnthis.locations.map((location:HandoffLocation)=>newHandoffLocation(location.id,location.name,location.openHours));}

这样页面修改自己的展示对象时，不会意外污染 Service 的权威配置。虽然当前模型很小，这个边界仍有助于保持数据所有权清晰。

五、时间也必须使用有限选项

当前时间段为：

• 今天 17:00–17:30；
• 今天 18:00–18:30；
• 明天 12:00–12:30。

有限时间片能避免用户在自由文本里夹带联系方式或模糊表达，也便于后续做确认期限、开放时间校验和提醒。

当前实现尚未把时间片与每个地点的开放时段做动态交叉校验，这是正式校园部署前需要补强的规则。

六、Service 不信任页面传入的 ID

页面只展示固定卡片不代表调用参数一定合法。HandoffService.propose()会重新检查地点 ID 和时间片是否存在：

constlocation=this.locations.find((item:HandoffLocation)=>item.id===locationId);if(!location||!this.timeSlots.includes(timeSlot)){returnnewOperationResult<HandoffRecord>(false,'请选择固定校内交接点和时间段');}

本地测试还专门传入UNKNOWN地点并断言失败。业务约束因此不依赖某一个 ArkUI 页面。

七、只有已接受的认领才能安排交接

固定地点不是独立预约功能。propose()首先读取 Claim，要求其状态必须为ACCEPTED。

这条门禁把链路固定为：

私密核验 → 同意认领 → 选择公共交接点 → 对方确认 → 双方线下完成。

如果 Claim 仍为PENDING，直接创建 Handoff 会绕过审核；如果 Claim 已取消或过期，继续预约会制造孤儿记录。

八、同一 Claim 不能重复创建活跃安排

Service 会查询已有 Handoff。只有旧记录为CANCELLED或EXPIRED时，才允许重新发起；其他活跃状态都会提示“交接安排已存在，请刷新后继续”。

这避免用户连续点击产生多个地点和多个时间。Repository 使用按claimId查询和 upsert 的模型，也让一条认领流程只有一个当前交接记录。

上图展示 ArkUI 地点卡片只提交locationId + timeSlot，Service 依据白名单补全名称和开放时间，Repository 保存受约束的HandoffRecord。

九、ArkUI 地点卡片如何表达选择状态

HandoffPage使用ForEach渲染地点卡片，选中项同时改变：

• 单选图标；
• 边框宽度和颜色；
• 卡片背景色；
• 无障碍文本中的“已选中”；
• selectedLocationId。

开放时段和地点名称保持为真实文本，不嵌入图片。这样字体放大、读屏和深色主题都能复用现有 token。

十、页面为什么明确写“不支持自由文本地址”

用户往往会把“没有输入框”理解为功能没做完。页面直接说明“不支持自由文本地址，也不会展示私人联系方式”，能把限制解释为安全设计。

好的隐私体验不仅是少收集数据，还要告诉用户为什么少收集。否则用户可能转而把手机号写进其他字段。

十一、交接完成前仍需要线下核验

固定地点只能降低暴露和环境风险，不能证明申请者就是失主。

页面和文章都应提醒：

• 不仅凭公开描述交付物品；
• 在公共服务点再次核对未公开细节；
• 贵重物品按校方或保卫处流程处理；
• 不要求对方提供支付、验证码或证件全号；
• 发现异常可以取消交接并重新开放记录。

地点安全与所有权判断是两个不同问题。

十二、当前地点只是演示配置

三条地点来自产品演示，不代表某所学校已经授权这些位置承担失物保管责任。

真实部署前需要校方确认：

• 地点是否真实存在并长期开放；
• 工作人员是否接受交接协助；
• 哪些物品必须移交保卫处；
• 贵重、危险或违法物品如何处理；
• 节假日与夜间开放时间；
• 责任边界与用户提示；
• 地点停用后的历史记录展示。

不能把一组写在代码里的地点名称描述成校方正式服务。

十三、正式版本应让配置可治理

地点与时间片未来可以来自受控配置 Repository，但不能让普通用户任意新增公共点。

配置至少需要：

• 稳定 ID 和显示名称；
• 启用状态；
• 开放时段与节假日例外；
• 支持的物品类型；
• 联系责任部门，但不向普通页面公开私人联系方式；
• 配置版本和更新时间；
• 历史 Handoff 的名称快照。

当前HandoffRecord保存地点名称和开放时段快照，可以降低配置改名后历史记录失真。

十四、为什么首版不需要精确定位和地图

三个固定公共点用卡片即可选择。接入定位或地图会增加权限、SDK、网络、坐标精度和审核说明成本，却不一定提高首版交接成功率。

项目选择不申请位置权限，也不采集精确轨迹。后续如果校园范围扩大，可以在不改变 Handoff 核心状态机的前提下增加校内导航，但仍应优先使用公共地点 ID。

十五、测试要覆盖哪些隐私约束

本地自动化至少验证：

• 未接受 Claim 不能发起交接；
• 未知地点 ID 被拒绝；
• 非白名单时间片被拒绝；
• 第一次安排成功；
• 同一 Claim 不能重复创建活跃安排；
• 取消或过期后可以重新发起；
• HandoffRecord不包含手机号和自由文本地址字段。

真机验收还应检查长地点名、字体放大、读屏选择状态、暗色模式与小屏时间片布局。

十六、用户体验与数据最小化是一致的

固定地点看似减少了自由度，却降低了填写成本、隐私判断成本和沟通成本。用户只需在已知公共点中选择，不必决定该不该透露手机号或私人位置。

当约束能同时减少风险和操作负担时，它通常比“先收集全部信息，再写一份隐私说明”更适合首版产品。

工程复盘：地点白名单需要版本、快照和退役策略

正式配置化以后，locationId不能只依赖当前列表是否存在。交接安排一旦创建，就应保存当时展示给双方的名称、说明和开放规则快照；否则管理员修改地点名称后，历史消息可能显示成另一个含义，已经约好的地点也可能在详情页突然消失。快照负责解释历史，最新配置负责限制新的选择，两者职责不同。

地点退役也不等于删除数据。一个交接点临时关闭时，新安排不再允许选择，但已有安排仍需要展示原地点，并给出改期或人工处理入口。若直接从白名单数组中移除对象，旧记录按 ID 回查会变成“未知地点”，用户反而更容易通过线下私聊交换私人地址。更稳妥的模型是保留稳定 ID，增加启用状态和有效时间，让 Service 在创建时拒绝不可用地点，在读取历史时仍能还原真实约定。

配置治理还需要明确责任边界。地点名称、值班时间和线下处理说明由校方或授权治理人员维护，普通用户只能选择，不能把任意文本伪装成公共服务点。配置更新应记录版本和修改原因，但日志只需要地点元数据，不需要附带认领者的私密核验内容。这样既能审计配置变化，也不会扩大敏感数据暴露面。

隐私验收不能只搜索“没有手机号字段”。测试人员还应确认网络请求、异常日志、埋点、分享文案和系统剪贴板都没有旁路采集联系方式；地点卡片在小屏、暗色模式和字体放大时仍能完整显示公共属性；过期或取消后，双方不能通过历史页面继续创建新的私人沟通入口。只有数据结构和真实交互都遵守最小化原则，固定交接点才真正降低隐私风险。

最后要验证降级体验。如果配置暂时加载失败，页面应进入明确错误态并允许重试，而不是退化成自由文本地址；如果没有任何可用地点，安排按钮应禁用并说明需要等待治理人员恢复服务。安全约束在异常路径里仍然成立，才不会出现“正常流程很谨慎，出错时反而收集更多信息”的反转。

十七、本文小结

安全交接不必从交换手机号开始。稳定的公共地点 ID、有限时间片、Service 白名单校验和显式隐私说明，可以在不采集私人地址与联系方式的前提下完成交接安排。

“寻迹校园”当前实现的是单机演示配置，不是校方正式地点服务；地点授权、开放时间治理、异常物品流程和真实身份权限仍需要正式部署方确认。

系列导航：第 28 篇 / 共 50 篇。上一篇：《认领状态机与 OPEN 恢复》；下一篇：《一次改期与 24 小时过期》。