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

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

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

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

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

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

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

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

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

固定地点模型只包含：

ts 复制代码

export class HandoffLocation {
  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：

ts 复制代码

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

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

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

当前时间段为：

今天 17:00--17:30；
今天 18:00--18:30；
明天 12:00--12:30。

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

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

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

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

ts 复制代码

const location = this.locations.find((item: HandoffLocation) => item.id === locationId);
if (!location || !this.timeSlots.includes(timeSlot)) {
  return new OperationResult<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 小时过期》。