EzStore:让每一次 App 交付都有据可查

做 App 的团队，往往不缺一个上传安装包的地方。

真正耗费时间的，是上传之后的那些事：哪个版本可以发给客户，证书还能用多久，新设备是否已经登记，安装失败卡在哪一步，审核结果有没有人跟进。

项目一多，这些问题就会分散在聊天记录、个人电脑和不同平台之间。开发在找证书，测试在等安装包，项目经理在反复确认进度。一个已经完成的版本，仍然需要不少人工协调才能交到使用者手里。

EzStore 希望把这些日常工作放到同一条线上：从应用上传、签名和分发，到设备安装入口，再到状态与通知回流，让每一次交付都有清楚的版本、条件和记录。

01｜应用和版本，先有一份清楚的记录

对开发公司来说，交付的基本单位不是一个文件，而是一个应用的持续迭代。

EzStore 支持接收 IPA、APK 和 AAB，解析应用信息，并把后续上传组织到对应的应用与版本记录中。团队可以围绕应用查看软件包、签名任务、分发入口和发布状态，减少靠文件名识别版本的负担。

较大的安装包可以使用可恢复的分片上传，在会话有效期内暂停、重新选择文件并继续传输；上传记录、校验和后续处理状态也能查询。

对外分享时，应用升级可以沿用固定短链接。客户和测试人员保留一个入口，团队则在后台管理新的包与交付条件。链接还支持暂停、恢复及安装码控制，让版本迭代与入口管理各有依据。

这带来的变化很具体：下次更新时，项目群里需要解释的事情少一些，后台里能够查清的事情多一些。

02｜把签名，从个人经验变成团队流程

iOS 交付中，证书、私钥、描述文件和开发者账号往往相互关联。材料散落在不同人的电脑上，交接和续期就容易变成临时排查。

EzStore 将账号与签名材料集中管理，区分租户自有、平台共享及指定范围使用的材料。商户自建材料保持本租户私有，证书、完整描述文件和私钥以密文保存，使用时仍需检查当前权限和材料状态。

发起签名后，任务进入异步队列，团队可以查看排队、执行、失败原因和产物结果。输出还需要经过平台独立验证，再进入后续交付流程。

已有代码关注的不只是“能不能签”，也包括“这次签的是哪个原包、用了什么材料、结果是否可以交付”。

材料维护也有相应入口：本地证书和描述文件可以更新，后续变更保留加密历史，并在当前权限与校验条件满足时恢复。版本更新或材料变更后，可以通过批量重签统一处理，不必逐个重复操作。

03｜让设备加入测试，有一条明确的路径

对需要按设备交付的 iOS 场景，签名之外，还要处理设备登记、审批和描述文件覆盖。

EzStore 已实现网页 UDID 采集、设备信息记录，以及应用级手动或自动审批。配置对应的自动交付策略后，获批设备可以进入 Apple 材料准备与签名队列，并在原应用入口等待相应产物。

这里有一个贴近日常维护的细节：同一团队、同一设备，会优先复用符合条件的旧设备记录、有效证书和匹配材料；当前原包与材料条件满足时，也可以复用已有签名结果。

复用以当前有效性为前提。 原包、证书、描述文件或设备准入发生变化后，平台会重新判断产物是否可用。团队因此能减少无必要的重复准备，同时保留每次交付的检查条件。

对于外包项目验收、内部测试和持续维护，这种流程化管理能减少“等某个人手动处理”的依赖。

04｜一个管理视角，容纳不同的发布渠道

同一个产品，可能既有 Android 测试包，也有 iOS 设备测试，还需要逐步走向官方商店。

EzStore 在应用管理之外，组织了不同渠道的交付路径：

• APK 直接分发：通过应用页面、短链接和二维码提供下载入口。

• 企业与 Ad Hoc IPA：结合对应签名材料、设备条件和下载授权提供 OTA 安装入口；企业分发用于符合条件的组织内部场景。

• 外部已签名 IPA：在支持的结构与验证范围内，检查后进入分发流程，无需把原签名私钥再次交给平台。

• TestFlight、App Store 与 Google Play：已有构建、测试组、资料、审核或发布相关工作流代码，具体开放范围以实际渠道验收为准。

AAB 用于官方发布流程，不作为网页直接安装的文件。

统一的是应用、账号与状态的管理视角，各渠道仍遵循自己的安装和审核流程。 上传完成、审核通过、正式发布和设备安装，分别代表不同的业务结果。

05｜交付之后，让状态回到团队

安装包发出去之后，项目经理还需要知道：任务有没有完成，审核是不是在等待，证书是否临近到期，剩余额度够不够下一轮交付。

EzStore 目前的反馈能力，首先体现在交付状态与业务消息回流。

站内通知集中呈现业务变化；已验证邮箱的用户可以选择接收业务邮件；团队也可以通过签名 Webhook，将已支持的事件送入自己的业务系统，并查询投递结果与重试记录。

服务与额度到期、低额度和已纳入范围的签名材料到期提醒，则帮助团队把维护安排前移。发生异常时，任务、操作和执行历史可以成为排查依据。

对于测试人员提交的问题描述、截图、复现步骤，以及应用内反馈和崩溃分析，仍需结合团队现有工具接续。当前项目中的支持工单属于待补齐范围。

把交付状态整理清楚，是后续处理测试意见、定位问题和安排下一次迭代的基础。

06｜多项目协作，需要清楚的权限和成本

当一家公司同时服务多个客户，或者一个平台承载多个团队时，方便操作之外，还需要清楚的边界。

EzStore 按工作空间组织应用、成员和资源，提供所有者、管理员、开发者及只读成员等角色。商户控制台、平台管理后台与公开安装页面分别承担不同任务，敏感材料与日常下载入口分开管理。

设备数、自有材料签名数和其他文件分发次数分别记录权益、预留和消费，订单、续费及退款也有对应状态。团队可以沿业务来源追查使用情况，而不是只面对一个含义模糊的总次数。

账号层面还提供可选 TOTP 双重验证、邮箱验证与密码找回等功能；操作记录帮助管理人员回看关键变更。

对开发企业而言，这些能力的价值在于：项目增加、人员变动时，交付工作仍然有清楚的归属和记录。

07｜从单机起步，为后续规模留出空间

EzStore 使用 Go、MySQL、Valkey，以及 Vue 3 与 Element Plus，默认面向 Linux 部署，前端资源可以内嵌到后端服务中。

文件存储已有 Local、OSS 和 MinIO 适配；签名采用独立 Worker 与异步队列，可配置并发。传输实现还覆盖同机受限文件交接、节点原包缓存和对象存储限时直传，以减少重复搬运安装包的开销。

历史签名包可以按保留策略进入清理流程，同时检查当前发布、下载和任务引用等保护条件。计划任务有执行历史，方便查看处理结果与失败原因。

这为团队提供了一个逐步发展的部署基础：先围绕当前业务建立稳定的交付方式，再根据安装包体积、任务量和组织规模安排扩展。

让团队把时间用在下一次迭代

对 App 开发公司而言，交付质量也体现在那些容易被忽略的日常细节里：版本找得到，材料有记录，设备有准入，安装入口清楚，异常有人跟进。

EzStore 围绕这些细节，将应用管理、签名、分发、设备和业务状态放进同一套工作流。

当开发、测试与项目管理能够沿着同一份记录协作，团队就有机会把更多时间留给产品本身。

让每一次 App 交付都有据可查，也让下一次迭代更从容。