第四篇：AppGallery 审核 3.1 实战：修复实验结果无法保存和分享的问题

摘要：这篇按一次真实审核问题来写：不是讲理论，而是把复现、定位、修复、回归和上架说明串起来。

本篇从审核反馈开始

这篇文章的价值在于真实问题复盘：审核说“实验结果无法保存数据和分享结果”，开发者不能只改按钮，而要把参数传递、结果模型、本地落盘、分享面板和提示状态全部串起来检查。它适合正在处理应用市场审核反馈的开发者阅读。

| 审核现象 | 技术落点 | 修复目标 |

| — | — | — |

| 结果无法保存 | DataStore、结果对象、记录页 | 保存后能在我的记录看到 |

| 分享不可用 | ShareKit、上下文、分享文本 | 能拉起系统分享面板 |

| 体验异常 | Toast、按钮状态、失败提示 | 用户知道当前操作结果 |

审核反馈先别急着改 UI

AppGallery 审核反馈里提到：“实验室-开始试验后查看实验结果无法保存数据和分享结果”。这种问题不能只理解成按钮样式不好，也不能简单加一个 Toast 就提交。它指向的是核心流程异常：用户完成实验后，结果没有可靠沉淀，也不能通过分享动作输出。

我的处理顺序是先复现，再看数据，再看按钮。复现路径必须和审核描述一致：进入实验室，开始试验，查看实验结果，点击保存和分享。只有按这条路跑一遍，才知道问题是在结果生成、保存服务、分享调用，还是页面状态。

第四篇｜3.1 问题修复架构

保存失败通常不是一个点坏了

实验结果保存涉及多个环节。结果页需要拿到 payload，payload 需要包含可保存字段，存储服务需要正常写入，页面需要显示成功或失败，历史记录需要能读出来。如果其中任何一环是假的，用户都会觉得“保存不了”。

分享也是一样。分享按钮不是摆设，它至少要生成一段可读文本，包括实验名称、实验现象、实验结论和时间。分享失败时要告诉用户原因，而不是静默无响应。

修复从统一结果对象开始

我先把实验结果整理成统一对象，而不是让保存和分享各自拼字段。这样保存服务和分享服务都接收同一份数据，避免两个出口内容不一致。

第四篇｜结果保存代码片段

代码里的校验很重要。如果结果对象不完整，应该在保存前失败，而不是把坏数据写进本地记录。审核时最怕“点了没反应”，所以失败也要可见。

页面只处理状态，不拼业务细节

结果页按钮的职责是触发动作、展示状态。比如 saving 为真时禁用按钮，成功后提示“已保存”，失败后提示“保存失败，请重试”。页面不应该知道底层存储细节，也不应该自己拼分享文本。

第四篇｜保存分享修复流程

这个流程修完后，我会用 release 包而不是 preview 页面测试。因为分享、签名、安装和权限在真实包里才更接近审核环境。

回归要覆盖用户能看到的每一步

这类问题修复后，回归清单不能只写“保存功能已修复”。我会逐项记录：能进入实验，能开始，能出结果，保存按钮有反馈，历史记录能看到，分享按钮能拉起分享能力，失败路径有提示。

第四篇｜3.1 回归检查清单

第四篇的经验是：审核 3.1 看的是用户实际能不能完成核心功能。按钮存在不等于功能存在，页面好看不等于流程闭环。把结果对象、保存服务、分享服务和回归证据补齐，才是能真正解决问题的修复。

为什么这类问题会被归到 3.1

审核指南里的稳定性问题不只包括崩溃。核心功能点了没反应、流程中断、结果丢失，也会被视为影响正常使用。实验室是这个应用的关键模块，用户完成实验后无法保存和分享，就等于学习结果无法沉淀，确实会影响体验。

所以修复时不能只看按钮事件有没有绑定，还要看用户任务是否完成。任务完成的标准是：用户知道保存成功，能在记录里找到结果，分享内容能被外部看到，失败时知道下一步怎么做。

日志和用户反馈要分开

开发时我们喜欢看日志，但用户看不到日志。保存失败时，如果只在控制台打印错误，审核人员看到的是“无响应”。页面必须把错误转换成用户能理解的提示，比如“保存失败，请重试”或“实验结果不完整，暂时无法保存”。

更好的方式是给保存和分享都设计明确状态：idle、running、success、failed。按钮根据状态禁用或恢复，Toast 根据结果展示。这样用户不会重复点击，也不会误以为应用卡住。

分享内容要避免内部实现痕迹

分享文本只应该包含用户能理解的信息，不要带内部字段名、文件路径、调试 ID。比如 payload.id=xxx 对用户没有意义，实验：酸碱中和；现象：颜色变化；结论：反应完成 才适合分享。

如果未来加入图片分享，也要注意权限和文件路径。离线教育应用尽量用系统分享能力，不要自己做复杂的后台上传。这样既降低隐私风险，也更符合应用定位。

回归证据要能复述给审核人员

修复完成后，我会准备一段很短的说明：本次修复实验结果保存与分享，完成实验后可保存到本地记录，也可通过系统分享输出实验摘要。审核人员不需要读代码，但需要知道怎样复测。

这段说明最好和包内功能一致。不要写“云端同步”“多人分享”这类不存在的能力。审核沟通越朴素，越容易通过。

复测时要准备干净环境

保存和分享修复后，最好清一次旧数据再测。旧缓存可能让你误以为保存成功，也可能让历史记录出现重复。干净环境能更准确地验证“从无到有”的完整路径。

我通常会先安装新包，打开应用，直接进入实验室跑一次最短实验，完成后保存，再去记录页查找；然后回到结果页测试分享。如果这条路径在干净环境里成立，才说明修复不是依赖旧数据。

分享测试不能只看按钮弹出

系统分享面板能弹出，只能说明调用到了分享能力，还不能说明分享内容正确。还要看分享文本是不是包含实验名称、现象和结论，是否有乱码，是否有内部字段，是否过长。

如果分享文本很差，用户依然会觉得功能粗糙。审核人员也可能认为分享结果不可用。因此分享内容本身就是体验的一部分，不只是 API 调用成功。

修复后的按钮状态也要防连点

保存和分享这类操作要防止连续点击。用户快速点两次保存，可能写入重复记录；连续点分享，可能拉起多个分享请求。页面可以在操作中把按钮置为不可点，等服务返回后再恢复。

这个细节对审核也有帮助。审核人员测试时动作很快，如果按钮状态没有处理，偶发重复或卡住会让问题更难解释。稳定的按钮状态，是核心流程稳定的一部分。

记录页也属于修复范围

保存成功后，如果记录页没有刷新，用户仍然会认为保存失败。所以修复不能停在结果页按钮上，还要确认记录页读取到了新数据。必要时在返回记录页时重新加载本地存储，避免列表停留在旧状态。

保存和分享必须成为可复测流程

AppGallery 审核反馈里提到“实验结果无法保存数据和分享结果”，这种问题不能只看按钮有没有绑定点击事件。真正要检查的是完整链路：实验页是否生成了结果参数，结果页是否正确接收，保存服务是否落盘，保存后是否有用户反馈，分享面板是否能正常拉起，失败时是否有可理解提示。

保存功能尤其要注意数据结构。如果今天保存的是一段字符串，明天要展示实验名称、参数、时间、结论和图表数据，就会发现旧结构不够用。所以实验记录最好从一开始就定义成对象，并保留版本扩展空间。这样“我的实验记录”页面、分享文本和后续导出功能都能复用。

分享功能则要遵循系统能力，不要自己做奇怪的外部跳转。ShareKit 的优势是用户可以选择系统支持的分享目标，应用只负责准备内容。教育应用分享实验结果时，文案要简洁：实验名称、关键参数、结论、数据摘要和来源即可，不要塞太多营销内容。

这类修复完成后，一定要做复测记录。建议按“开始实验 -> 进入结果 -> 保存数据 -> 我的记录查看 -> 分享结果 -> 返回页面”跑一遍。如果任何一步没有反馈，用户都会觉得功能坏了；如果审核人员复现不出来，也容易再次被打回。

实战复盘：审核修复要留下复测路径

| 检查点 | 为什么重要 | 怎么验证 |

| — | — | — |

| 从实验页进入结果页 | 确认参数没有丢 | 完成一次完整实验流程 |

| 保存后可回看 | 证明不是只显示提示 | 打开我的实验记录 |

| 分享面板可拉起 | 证明系统能力调用成功 | 点击分享并观察系统面板 |

审核修复文章要高质量，最关键是写清楚“问题如何被复现”。只写最终代码不够，因为读者真正需要的是定位思路：先确认数据源，再确认存储，再确认系统能力，最后确认用户反馈。

也想请你帮忙体验一下

如果你也遇到过上架审核里的保存、分享、稳定性问题，可以下载「化学实验室」实际跑一下实验结果流程。麻烦体验后帮我评论一下保存和分享是否顺畅，哪怕一句建议也很有用。应用能继续更新，离不开真实用户的下载和反馈。