【寻迹校园 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:00LIBRARY_1图书馆一层服务台08:30–21:30SECURITY_EAST东门保卫处失物招领点全天开放稳定 ID 用于持久化和判断名称与开放时段用于展示。未来文案变化时不应因为“图书馆一层服务台”改名就破坏历史记录关联。四、为什么返回地点列表时要复制对象getLocations()不直接暴露内部数组而是创建新的HandoffLocationgetLocations():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 和时间片是否存在constlocationthis.locations.find((item:HandoffLocation)item.idlocationId);if(!location||!this.timeSlots.includes(timeSlot)){returnnewOperationResultHandoffRecord(false,请选择固定校内交接点和时间段);}本地测试还专门传入UNKNOWN地点并断言失败。业务约束因此不依赖某一个 ArkUI 页面。七、只有已接受的认领才能安排交接固定地点不是独立预约功能。propose()首先读取 Claim要求其状态必须为ACCEPTED。这条门禁把链路固定为私密核验 → 同意认领 → 选择公共交接点 → 对方确认 → 双方线下完成。如果 Claim 仍为PENDING直接创建 Handoff 会绕过审核如果 Claim 已取消或过期继续预约会制造孤儿记录。八、同一 Claim 不能重复创建活跃安排Service 会查询已有 Handoff。只有旧记录为CANCELLED或EXPIRED时才允许重新发起其他活跃状态都会提示“交接安排已存在请刷新后继续”。这避免用户连续点击产生多个地点和多个时间。Repository 使用按claimId查询和 upsert 的模型也让一条认领流程只有一个当前交接记录。上图展示 ArkUI 地点卡片只提交locationId timeSlotService 依据白名单补全名称和开放时间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 小时过期》。