简介一套Java与Vue开发的苹果iOS超级签名源码包附带安卓合并分发页面面向需要搭建签名分发平台的开发者或站长。功能覆盖登录注册、共有池证书管理、用户自行上传证书、分发页轮播与简介配置、签名后对接阿里云OSS、七牛云或本地存储下载以及查看用户下载记录形成证书上传到分发追踪的完整闭环。压缩包共22个文件打包后约33.7MB包含后端程序与配置、前端页面、数据库初始化脚本以及签名描述文件、安装配置清单和签名工具模板目录区分签名模块、临时文件、配置等层级便于二次部署。已有583人学习下载适合具备Java基础并熟悉CentOS、MySQL等环境的开发者参考。包内附部署所需证书文件夹、数据表结构与关键配置文件可帮助理解超级签名整体流程、减少从零搭建时的踩坑成本。1. 超级签名能不能自己搭这套 Java 源码把分发页也备好了我们有个内测应用在 TestFlight 上被拒了两轮第三方签名平台又按设备数收费团队后端直接甩给我一个仓库苹果 iOS 超级签名的 Java 源码包带分发页面还能把安卓应用合并到一起管理。起初我以为是换皮项目实际拆完后发现这条链路确实完整——用户在网页上被采集到 UDID后端自动调 Apple 开发者接口把设备注册进描述文件再用签名工具对 IPA 做重签最后生成 itms-services 协议的可点击安装链接。它解决的问题很实际不需要把 IPA 交给第三方不需要每个测试设备都连 Xcode安卓和 iOS 还能共用一个后台。适合正在搭内测分发平台的 iOS 开发者、需要批量上报设备 UDID 的团队以及想弄清楚超级签名背后到底调了哪些 Apple 接口的 Java 工程师。2. 超级签名平台是怎么工作的从安装链路看四个核心角色2.1 超级签名和企业签名先分清再动手我们常把“超级签名”挂在嘴边但在 Apple 官方文档里其实没有这个词它是开发者对一种分发方式的叫法。要理解这套源码第一步是区分两种签名机制机制账号类型设备限制主要风险超级签名Ad Hoc 分发个人/公司开发者账号$99/年同一描述文件累计注册设备上限 100 台注册设备数到顶后需要重建描述文件企业签名In-House 分发企业开发者账号$299/年设备无上限但证书吊销风险高企业证书一旦被 Apple 封禁所有设备全部失效超级签名走的是 Ad Hoc 这条路把测试设备的 UDID 写进 provisioning profile描述文件再用对应的证书对 IPA 做签名。它的优势是证书更“干净”因为是标准开发者账号签署不会像企业证书那样容易被批量吊销劣势也明确单份描述文件只有 100 台设备的额度所以当设备数量上涨时平台要动态维护多套 App ID 和描述文件把注册了不同设备的用户分流到不同下载通道。这也是源码包存在的意义你不可能手动去开发者后台一台一台设备加 UDID平台通过后端接口把“注册设备 → 生成描述文件 → 签名 → 分发”这条链路自动化了。所以判断一个超级签名源码包写得好不好不是看它能不能装而是看它对“设备额度池”的管理策略是否收敛。2.2 一条安装链路里的四个核心环节普通用户眼里安装就是“打开网页 → 点一下 → 手机开始下载 App”。但在服务端视角里这条链路要拆成四段每段都是一个独立接口采集 UDID用户用 Safari 打开分发页面时服务器下发一个描述文件.mobileconfigiOS 会提示“允许安装描述文件”安装后系统会把 iPhone 的 UDID 回调到服务器指定接口。注册设备后端拿到 UDID 后调用 Apple Developer 的后台接口把设备注册到开发者账号名下并把它加进某个 App ID 的 provisioning profile。重新签名注册完成后后端把原始 IPA 和最新的描述文件一起交给签名程序生成一个新的、包含这台设备的 IPA。生成安装页把新的 IPA 放到可访问的 CDN 或服务器目录同时拼装一个 plist 清单文件前端页面把它转成 itms-services 协议链接用户点击后直接唤起安装。这四个环节不是顺序执行一次就完了。平台里会有很多 App每个 App 有多个版本设备可能在不同时间涌入所以签名动作往往是异步的。用户点“安装”后端先创建一条任务设备轮询任务状态等签名完成后页面才显示下载按钮。这也是后端代码里最值得读的部分——任务状态机设计。2.3 为什么这套源码用 Java 写选型理由和模块边界市面上的超级签名开源项目不少但用 Java 写的其实不多。拆完这套源码包我理解它选 Java 的理由主要有三个Spring Boot 生态成熟做接口、做后台管理页面、对接微信或第三方登录都很顺一名 Java 工程师拿到就能改。并发任务更好排队签名是 CPU 密集型操作zsign 本身是独立进程Java 负责编排进程配合 Redis 队列可以控制同时跑几个签名任务不至于把服务器压垮。部署环境宽容很多签名工具需要 macOS但 zsign 这类命令行工具在 Linux 上也能跑Java 的服务端代码没有系统绑定一台 4 核 8G 的云主机就能承载小型团队的内测分发。模块边界上目录一般会分成controller页面回调接口、service签名任务编排、apple-api封装 Apple 开发者接口、utilzsign 封装、plist 生成数据库表至少会涉及app_info应用信息、device_info设备 UDID 表、sign_task签名任务表和download_url分发地址表。后端骨架长这样RestController RequestMapping(/api/v1/distribute) public class DistributeController { PostMapping(/udid) public Result udidCallback(RequestBody String udidPayload) { // udidPayload 是 iOS 回调上来的 plist/XML里面包含设备的 UDID 和机型信息 String udid parseUdidFromProfile(udidPayload); // 幂等处理同一台设备注册过就直接返回已有状态 DeviceInfo device deviceService.registerDevice(udid); // 异步触发签名任务避免用户请求被长时间挂起 signTaskService.enqueue(device, currentAppId()); return Result.ok(udid received); } }这段代码里的parseUdidFromProfile是解析 mobileconfig 回调体的工具方法registerDevice做两件事先查本地表里是否已存在这条 UDID不存在则插入enqueue是异步入口实际签名放到队列消费线程池里执行。参数设计上UDID 是 40 位十六进制字符串机型不参与签名逻辑但建议存下来方便后面做安装数据统计。2.4 苹果开发者接口老接口和新接口的兼容问题这套源码对 Apple API 的封装方式决定了它在当前环境还能不能跑通。早期超级签名项目普遍调用https://developer.apple.com/services-account/v1/这类网页接口先登录开发者后台拿 session然后操作设备注册。后来 Apple 更新了认证体系强制使用 App Store Connect API KeyJWT 方式或双因素认证很多老项目拿到手后第一步就是 401。源码包里通常会把认证逻辑集中在一个类里比如AppleApiClient。你拿到手后要做的第一件事不是改业务代码而是确认这个类用的是哪种认证。如果用的还是旧式账号密码登录建议把authKey和authKeyId相关配置找出来改成 JWT 鉴权。否则后面所有设备注册接口都会报 401整个流程跑不通。这部分对接通常在项目文档或配置注释里会提到没有的话就按 App Store Connect API 的规范补一份 .p8 密钥文件这是当前最稳的方案。3. 把源码包跑起来环境准备到分发页面上线3.1 先别急着部署把这三个文件看明白拿到源码包我会建议先花半小时看三个文件比直接mvn spring-boot:run有效得多README.md重点看它的环境要求是 JDK8 还是 JDK11MySQL 版本号Redis 是否需要密码zsign 是自带还是要自己编译。很多问题是版本不匹配造成的提前排除能省半天。application.yml关注apple开头的配置块、upload.path、download.domain三项。前两个决定签名是否成功download.domain决定生成的安装链接是否有效。db/init.sql看设备表有没有唯一索引签名任务表的状态枚举有哪些。如果表结构里没有device_id唯一索引注册接口在高并发下会出现重复设备后面签名描述文件里会出现同一设备多行记录导致 Apple 后台拒绝。初始化 SQL 脚本属于你应该先跑起来的东西。常见的坑是 MySQL 字符集没设utf8mb4导致 UDID 或者设备型号里的 emoji 字符插入报错遇到这种就直接清库重建别浪费时间诊断。3.2 环境速配JDK、MySQL、Redis、zsign 四件套先看清单依赖版本建议用途JDK1.8 或 11运行 Spring Boot 服务MySQL5.7 或 8.0存应用、设备、签名任务Redis3.2 以上异步任务队列、计数zsign0.4.x 最新编译版命令行 IPA 重签工具在 Ubuntu 20.04 上我的习惯是用包管理器装好基础环境然后单独编译 zsign因为 zsign 依赖 openssl系统自带的可能版本不对签名时会出现奇怪的报错。# 基础环境安装Ubuntu/Debian 系 sudo apt-get update sudo apt-get install -y openjdk-11-jdk maven mysql-server redis-server build-essential libssl-dev # zsign 编译源码目录里一般自带 zsign/ 子模块 cd zsign make -j$(nproc) make install zsign --help | head -20代码说明build-essential和libssl-dev是编译 zsign 必需的maven 用来拉 Java 依赖zsign --help用来确认工具能正常执行。zsign 的输出里会看到zsign version xxx和参数说明如果这里直接报动态库缺失说明 openssl 开发包没有装全需要在服务器上执行ldd zsign查看具体缺失项。这个步骤做完环境准备基本结束。3.3 这份源码里必须改的配置项配置文件的修改是部署过程的核心。下面这份 application.yml 是典型的超级签名平台配置注释标出了优先级最高的几个点server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/supersign?useUnicodetruecharacterEncodingutf8mb4autoReconnecttrue username: root password: change-me redis: host: localhost port: 6379 supersign: # 证书文件路径.p12 导入的开发者证书密码必须写对 p12-path: /opt/sign/cert.p12 p12-password: ${P12_PASSWORD} # 描述文件路径至少要有一个可用的 .mobileprovision mobileprovision-path: /opt/sign/adhoc.mobileprovision # 签名临时输出目录 output-path: /data/signed-apps/ # 下载域名公网必须能用 https 访问到 output-path 下的文件 download-domain: https://dl.example.com apple: # 使用 App Store Connect API Key 时需要下面三个参数 auth-key-id: ABC123 auth-key-file: /opt/sign/AuthKey_ABC123.p8 app-id: com.example.enterprise参数说明p12-password不建议硬编码用环境变量P12_PASSWORD传入这样服务器日志里不会泄露证书密码download-domain必须填能公网访问的 https 域名iOS 的 itms-services 下载强制要求 https证书越界都会导致安装失败。apple.auth-key-id是 App Store Connect 里生成的 API Key IDauth-key-file是下载的 .p8 文件路径这两个必须配套。这里有个容易被忽略的点.mobileprovision文件是有有效期和团队绑定的源码包里自带的描述文件大概率是作者的开发者账号生成的你拿到后必须换成自己的否则就算签名成功安装到真机也会因为证书不匹配而失败。更换后重启服务再用profiles list -d之类的方式确认证书链正常。3.4 启动后先别急着发链接做一轮自检服务启动后我习惯先打一轮接口自检而不是立刻让用户扫码。自检的三个关键点接口/操作预期结果失败时看什么GET /health返回 JSON 且 statusUP日志里数据源连接是否正常上传一个测试 IPA返回 taskId状态变成 SIGNING是否卡在签名队列zsign 是否可用访问生成的下载页页面显示“等待安装”按钮域名是否配置正确CDN 缓存是否过期第一次启动最常见的问题是数据库表结构没有自动生成。如果源码里没有集成 FlywaySQL 脚本就得手动导入mysql -uroot -p supersign db/init.sql curl -s http://localhost:8080/health导入 SQL 时如果报Unknown collation说明脚本是在新版 MySQL 上导出的你要做的是把脚本里的utf8mb4_0900_ai_ci全部替换成utf8mb4_unicode_ci然后重新导入。curl /health返回的内容里如果带error字段优先看后端的堆栈日志不要猜。4. 核心流程拆解UDID 采集、自动重签到分发下载4.1 手机 UDID 是怎么被后端拿到的一个 mobileconfig 的完整使命超级签名平台从用户在浏览器里点“开始安装”那一刻起后端就要开始引导设备交出 UDID。实现方式是让用户安装一个配置描述文件.mobileconfig这个文件本身很简单核心是PayloadType必须等于Profile Service并且把回调地址写进URL字段。?xml version1.0 encodingUTF-8? plist version1.0 dict keyPayloadContent/key dict keyURL/key stringhttps://yourdomain.com/api/v1/distribute/udid/string /dict keyPayloadIdentifier/key stringcom.example.udid/string keyPayloadType/key stringProfile Service/string keyPayloadVersion/key integer1/integer /dict /plist逻辑说明这个文件就是给 iOS 系统看的“设备信息上报任务”苹果规定的 Privacy 描述文件只要带Profile Service类型系统就会在设备上弹一个“允许”框用户点击后iPhone 自动把 UDID 用 TLS 安全回传到URL字段写的接口。注意PayloadIdentifier要全局唯一同一个包重复安装会覆盖。参数说明PayloadVersion固定 1 即可无需改动回调接口必须是浏览器可访问的公网地址不能用 IP因为 iOS 对描述文件的处理走的是系统网络栈部分网络环境会强制拦截非 https 请求。实际生产环境中我见过直接把这个 xml 输出到 controller 的写法请求进来后设置Content-Type: application/x-apple-aspen-config就能触发 iOS 安装描述文件的引导页。4.2 自动重签在 Java 里调用 zsign别自己包一层密钥库操作拿到 UDID、完成 Apple 后台注册之后关键一步是重签 IPA。很多团队想用 Java 原生去改 Mach-O 的签名信息这是非常不建议的做法。靠谱的方案是后端用ProcessBuilder调用 zsign 命令行工具只负责传参和接收退出码。ProcessBuilder pb new ProcessBuilder( zsign, -k, p12Path, -p, p12Password, -m, mobileprovisionPath, -b, bundleId, -o, outputIpaPath, inputIpaPath ); pb.redirectErrorStream(true); Process process pb.start(); try (BufferedReader reader new BufferedReader(new InputStreamReader(process.getInputStream()))) { String line; while ((line reader.readLine()) ! null) { log.info(zsign: {}, line); } } int exitCode process.waitFor(); if (exitCode ! 0) { throw new SignException(zsign exit code: exitCode); }逻辑说明-k指定 P12 开发者证书的绝对路径-p是证书密码-m是当前设备所属描述文件-o是输出路径最后一个是原始 IPA 路径。redirectErrorStream(true)把 stdout 和 stderr 合并到一起方便在一个流里看 zsign 的完整日志。exitCode非 0 表示签名失败此时要立刻记录日志并把这个任务改成失败状态而不是继续让用户等待下载。参数说明-b传入 bundleId 是可选但建议填写的参数因为描述文件里可能包含多个 App ID明确指定它可以让 zsign 在签名过程中保持版本号与原 IPA 一致避免出现改了 bundleId 导致手机无法覆盖安装的尴尬情况。签名输出目录建议和服务端静态文件目录分开并用download-domain直接映射到这个目录。4.3 分发页面的核心itms-services 协议与 plist 拼装当 IPA 重新签名完成用户真正点击安装时iOS 并不能直接下载 .ipa 文件它需要一个 plist 清单然后通过itms-services协议唤起安装。这一步的拼装逻辑直接决定用户能不能装上很多平台“下载进度条不动”都是这里出了问题。?xml version1.0 encodingUTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd plist version1.0 dict keyitems/key array dict keyassets/key array dict keykind/key stringsoftware-package/string keyurl/key stringhttps://dl.example.com/apps/myapp.ipa/string /dict /array keymetadata/key dict keybundle-identifier/key stringcom.example.app/string keybundle-version/key string1.2.0/string keykind/key stringsoftware/string keytitle/key string企业内测版/string /dict /dict /array /dict /plist逻辑说明iOS 拿到这个 plist 后会读取assets里的下载地址必须是 https 直链然后把metadata里的bundle-identifier和bundle-version与手机里已安装的版本做对比决定能否覆盖安装。所以 plist 不是死模板IPA 每次重签后bundle-version都要从原 IPA 里读出来再填进去。参数说明software-package这一项如果同时存在多个iOS 会默认下载第一个所以如果平台支持按设备类型分发不同架构包排序逻辑要额外注意title会显示在安装弹窗上建议填可辨识的版本号后缀否则测试同事分不清装的是哪个包。4.4 安卓合并不是把签名技术搬过去而是把分发入口统一起来源码包标题里提到的“支持安卓合并网站源码”指的是分发页面和管理后台可以同时承接 APK 分发。安卓不存在描述文件签名的概念所以后端要做的只是对 APK 做基本的 metadata 管理上传后直接把 Apk 链接给用户。同一个网站iOS 用户看到“点击安装描述文件”的流程安卓用户看到“直接下载 APK”按钮。实现上通常是在前端页面做 UA 判断后端只负责把 iOS 和安卓的下载地址维护在resources表里前端根据navigator.userAgent渲染不同入口。这个合并的真正价值是让团队只需要维护一套管理后台不需要在两个系统里分别纠结算法和统计。5. 避坑部署超级签名平台常见的 5 个“玄学”问题5.1 证书明明有效签名后安装却说无法安装现象后端日志显示 zsign 签名成功exitCode 为 0用户点击安装后手机提示“无法安装 App”。原因绝大多数情况是描述文件里的设备列表没有包含当前这台 iPhone。签名过程中 zsign 只负责把描述文件嵌进 IPA如果mobileprovision里没有这台设备的 UDIDiOS 在安装阶段会直接拒绝而签名阶段不会报错。这就是为什么平台必须先注册设备再触发签名设备表里漏一步后面就全错。解决把签名链路改成“先查询 device_info 表确认 UDID 已存在再创建签名任务”。同时每次生成新的描述文件后可以在测试机上用 Apple 官方提供的CFUUID读取工具或开发者后台的设备列表交叉验证确保该 UDID 确实出现在描述文件里。遇到这类问题时最有效的排查是打开 iPhone 的系统日志搜“provisioning”。5.2 进度条到 80% 就停住日志里只有网络异常现象用户下载到一半进度卡住随后提示下载失败。原因itms-services 下载安装时iOS 对 IPA 链接有强制条件必须使用 HTTPS而且服务器的 TLS 证书链必须完整。如果你把 IPA 放在 CDN 上CDN 的中间证书没有配全就会出现“前面握手成功传一半断连”的诡异现象。解决不要只测curl能不能下载用curl -Iv https://dl.example.com/apps/test.ipa看证书链输出确认SSL certificate verify ok如果用的 CDN把 CDN 的中间证书和根证书都配上。另一个常见小坑是文件名里带中文或空格iOS 的 URLSession 遇到非 ASCII 字符会截断统一改成拼音或日期命名的 IPA比如app_20250412_v120.ipa。5.3 调用 Apple API 返回 403 或 401设备注册总是失败现象后端日志里调用设备注册接口返回 HTTP 403或者 App Store Connect API 返回INVALID_AUTH_KEY。原因这类问题九成出在认证配置上。旧式账号密码登录方式已经被 Apple 限制新项目再怎么做也无法用它完成注册新版 JWT 认证如果 .p8 文件内容不对、Key ID 不匹配、或者密钥权限只开了 Finance 没开 Developer 权限都会报 403。另一个隐蔽点是 JWT 过期时间不能超过 20 分钟代码里如果用了固定的 1 小时有效期必然会被 Apple 拒绝。解决打开 App Store Connect 后台确认这个 API Key 的 Access 里开启了Developer权限检查生成 JWT 的代码里exp设置为当前时间 15 分钟同时用官方提供的 JWT 验证工具先验一遍。真机上如果日期时间不准也会因为时间校验失败产生 401但通常服务器和 Redis 都不会是这个原因先检查这两个点就行。5.4 安卓扫码正常iOS 页面一直转圈不弹安装现象同一个分发链接安卓手机打开能看到“直接下载”按钮iPhone 打开页面一直 loading或点击后没有任何系统弹窗。原因前端默认用了安卓的 UA 判断逻辑导致 iOS 用户被识别成“未知设备”页面没有渲染出正确的跳转按钮或者按钮的href没有拼接成itms-services://?actiondownload-manifesturl...而是直接放了 https 链接。解决在页面初始化时打印日志里加上User-Agent字段确认 iOS 的 UA 中是否包含iPhone或iPad。按钮链接必须由后端返回一次性生成的 plist 地址不要在前端用字符串拼接拼接时至少确保download-manifest后的 url 参数先做encodeURIComponent编码否则 plist 地址里带?或时会被系统解析错乱。5.5 并发签名任务一多服务器 CPU 直接打满现象三个人同时传包服务器 CPU 持续 100%zsign 进程互相竞争最后所有任务超时失败。原因zsign 是 CPU 密集型的单进程程序它没有自带并发控制。如果后端每收到一个请求就立刻启动一个 zsign 进程10 个任务就是 10 个进程同时抢 CPU磁盘 IO 也跟着竞争整个服务直接失去响应。解决把签名操作放进一个线程数为 2 的线程池队列用 Redis 做持久化类似前面代码里的signTaskService.enqueue()。更保险的做法是设置一个全局信号量Semaphore(2)任务进入前先拿许可拿不到就排队等待。这样即使瞬时来了 50 个任务系统也能逐个消费。线上我一般还会给 zsign 进程配置 CPU 亲和性防止它把服务进程的 CPU 抢光。6. 进阶从“能安装”到“稳定分发”的验证闭环6.1 用一条命令自查签名完整性很多平台签名成功后没有二次验证直接把 IPA 丢给用户等到手机上报“无法安装”才发现是描述文件没匹配。我会在签名任务结束前加一步自动校验用 zsign 的校验参数看看 IPA 内的描述文件和证书是否匹配zsign -d /data/signed-apps/myapp.ipa执行后如果输出里包含provisioned devices列表和team identifier说明签名信息完整。如果输出里只有安装包名但看不到设备列表基本可以判定描述文件是旧的需要重新生成。这一步属于“读日志不如见数据”的典型场景把zsign -d的输出落库还能在后台做一个签名健康度报表。6.2 描述文件轮换别等 100 台额满才动手Ad Hoc 描述文件的设备上限是 100 台一旦注册满后面所有新设备都无法安装旧设备也会因为描述文件版本过旧而可能失效。所以稳定分发的关键不是“坏了再修”而是周期动作。我会写一个定时任务每两小时检查一次设备表中已注册且未安装的设备数量如果接近 80%自动从开发者后台拉取新的描述文件然后构建一条新的下载通道。新老描述文件并行存在老通道的设备不受影响新设备走新通道。这个操作要配套一个版本号字段给用户侧否则用户缓存的老安装页会一直访问同一个失效链接。从那以后我每次部署这类平台都会强制走一遍同样的流程先zsign -d验证签名产物再检查 .mobileprovision 的有效期和注册设备数最后分发页面用 iPhone 真机点一轮。这套流程看起来机械但确实能提前暴露大部分“玄学”问题。希望帮到你。本文还有配套的精品资源点击获取