简介：面向iOS开发者和应用测试人员，这份全开源版本签名网站系统源码提供了一套完整的IPA在线签名解决方案。系统支持UDID自动获取、多款软件选择、签名码生成与应用签名，并允许多开APP安装，可帮助用户在不安装Xcode等复杂工具的情况下完成应用签名与多设备测试部署，尤其适合需要频繁调试或批量分发的场景。资源包共2000个文件，以1795个json配置数据、149个md说明文档、51个html页面为主，另含2个sql数据库脚本、2个txt文件及1个js脚本，压缩包大小76.66MB，整体涵盖前端页面、后台控制、数据库结构等完整站点所需部件。配套环境为Nginx+PHP7.4+MySQL5.6，方便站长快速搭建部署。目前已有289人学习下载，可直接基于源码二次开发或投入生产使用，省去从零搭建签名系统的繁琐过程。
1. 这套 iOS 签名网站到底拆出来有什么
先给结论：这不是一个“装好就能用”的傻瓜包，而是一套把 UDID 获取、IPA 在线重签名、描述文件安装、应用多开串在一起的 PHP 业务系统。站长用 Nginx + PHP 7.4 + MySQL 5.6 就能跑，前端入口是 index.html，后台逻辑分布在 install、config、control、edit 这些页面里。说“全开源”意味着你能看到签名码怎么生成、UDID 怎么回流、IPA 上传后走哪条命令落盘，而不是被黑盒接口卡住。
适合谁用？第一类是自己玩 TestFlight 之外的内部分发，不想每次打开 Xcode 重签的 iOS 开发者；第二类是给小团队做设备管理、批量安装测试包的运维；第三类是研究在线签名链路、想自己搭分发平台的技术人员。需要提前说清楚：这套系统不包含 Apple 开发者证书，它做的是把“证书 + 描述文件 + IPA”组合成可安装包的流程自动化，证书和描述文件你得自己备好。下面从系统目录开始拆，把每条链路都过一遍。
2. 系统结构与请求链路：从 index.html 到签名落盘
2.1 入口页与配置页各自承担什么职责
先看最表层的文件。index.html 是用户看到的落地页，通常承担三件事：展示可签名的软件列表、引导用户点击“获取 UDID”、提交签名码。install.html 负责接收来自苹果的 UDID 回调，这一页很关键，因为 UDID 的获取本质上是让用户安装一个描述文件，然后苹果服务器把设备信息 POST 到 install.html 上。config.html 和 control.html 是后台管理入口，前者处理站点配置、证书描述文件上传，后者控制签名任务状态。edit.html 则是编辑软件列表、调整展示信息的页面。
这套结构把前台展示和后台管理分开了，但全开源的好处就是你能直接改逻辑。例如 index.html 里的软件列表若没有走数据库而是写死在 HTML 中，就需要去 edit.html 对应的处理接口里看是更新了 JSON 还是更新了表记录。常见做法是软件列表存在 MySQL 表中，edit.html 提交后通过 PHP 写入，index.html 用 PHP 读取输出。如果你拿到手的版本里 index.html 是纯静态的，说明软件列表是动态接口渲染的，翻一下同目录下的 PHP 文件就能找到数据源。
2.2 UDID 获取链路：描述文件与回调解析
UDID 获取是整套系统的地基。流程分三步：前端触发安装描述文件，描述文件中的 URL 指向 install.html，苹果服务器将设备信息以 XML 格式 POST 到这个地址，然后 PHP 解析 XML 取出 UDID。描述文件本质是一个 signed.mobileconfig，它不需要开发者证书，用 plist 格式写即可。
关键的 mobileconfig 示例如下（注意 URL 要换成你自己的域名路径）：
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PayloadContent</key> <dict> <key>URL</key> <string>https://yourdomain.com/install.php</string> <key>DeviceAttributes</key> <array> <string>UDID</string> <string>IMEI</string> <string>VERSION</string> <string>PRODUCT</string> </array> </dict> <key>PayloadOrganization</key> <string>Your Org</string> <key>PayloadDisplayName</key> <string>UDID Getter</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadUUID</key> <string>any-unique-uuid</string> <key>PayloadIdentifier</key> <string>com.example.udid</string> <key>PayloadDescription</key> <string>This profile is used to get UDID.</string> <key>PayloadType</key> <string>Profile Service</string> </dict> </plist>这段配置里最关键的是PayloadType必须是Profile Service，同时PayloadContent中的 URL 指向 install.php。用户在 Safari 中打开该描述文件链接时，系统会弹出“允许描述文件”的提示，安装后设备会向上述 URL 发送一个编码的 plist 请求。install.php 中需要用file_get_contents('php://input')拿到原始请求体，再用plist_decode或simplexml_load_string解析出 UDID。
$data = file_get_contents('php://input'); $plist = new SimpleXMLElement($data); $udid = $plist->dict->dict->string[0]; // 某些 iOS 版本返回的层级不同，建议先打印整个 XML file_put_contents('udid.log', $data . PHP_EOL, FILE_APPEND); echo '<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"><dict> <key>PayloadContent</key> <dict> <key>URL</key> <string>https://yourdomain.com/sign.php?udid=' . $udid . '</string> </dict> <key>PayloadType</key> <string>Profile Service</string> </dict></plist>';注意返回给设备的内容必须也是一个描述文件，否则 Safari 会提示安装失败。返回描述文件的作用是引导设备跳转到签名页并带上 UDID 参数。此处的dict->dict->string索引可能因 iOS 版本不同而变化，建议先记录原始 XML 再调整解析逻辑。另外，如果服务器没有启用 HTTPS，iOS 13 及以上版本会直接拦截描述文件下载，所以上线前必须配置好 SSL 证书，这是最容易踩的坑之一。签名码可以是一次性的，也可以绑定 UDID，这取决于 config 中怎么设置。
2.3 IPA 签名流程与前端交互参数映射
IPA 在线签名是本系统的核心动作。用户在前端选择一个 App，输入签名码，点击“签名并安装”后，前端请求后端接口。后端拿到待签名 IPA 的路径、签名码、UDID（如果有），先校验签名码是否有效，再检查 IPA 文件是否存在，然后调用签名工具执行重签名，最后把签名后的 IPA 暴露为可下载链接。
前端表单一般长这样：
<form action="sign.php" method="post" enctype="multipart/form-data"> <input type="hidden" name="app_id" value="1001"> <input type="text" name="sign_code" placeholder="请输入签名码"> <input type="hidden" name="udid" id="udid_input"> <button type="submit">签名并安装</button> </form>这里的 app_id 是软件列表中的唯一标识，后端通过它找到服务器上对应的原始 IPA 文件路径。sign_code 用来验证用户是否有权限执行签名；UDID 则用于描述文件与设备绑定。如果系统支持多开安装，那么还要传入一个 instance_id 参数，后台复制一份 IPA 并修改 bundle identifier，例如把com.example.app改成com.example.app.dup1，再重新签名，这是多开的技术本质。
sign.php 中常见的处理流程如下：
$app_id = $_POST['app_id']; $sign_code = $_POST['sign_code']; $udid = $_POST['udid']; // 1. 校验签名码 $row = query("SELECT * FROM sign_codes WHERE code = '$sign_code' AND status = 0"); if (!$row) exit('签名码无效或已使用'); // 2. 获取 IPA 路径 $app = query("SELECT * FROM apps WHERE id = $app_id"); $ipa_path = '/data/ipa/' . $app['file_name']; // 3. 生成临时工作目录 $work_dir = '/tmp/sign_' . time(); mkdir($work_dir, 0755, true); // 4. 解压 IPA（本质是 zip） exec("unzip $ipa_path -d $work_dir/app", $out1, $ret1); // 5. 替换描述文件 copy('/certs/profile.mobileprovision', $work_dir . '/app/Payload/xxx.app/embedded.mobileprovision'); // 6. 修改 Bundle ID（多开时） if (!empty($_POST['instance_id'])) { plist_change_bundle_id($work_dir . '/app/Payload/xxx.app/Info.plist'); } // 7. 重签名 exec("codesign -f -s 'Your Certificate Name' $work_dir/app/Payload/xxx.app", $out2, $ret2); // 8. 重新打包 exec("zip -r /data/signed/app_{$app_id}_{$udid}.ipa $work_dir/app/Payload", $out3, $ret3);这段代码中，unzip与zip依赖系统安装 zip 工具，codesign是 macOS 或装有 Xcode 命令行工具的 Mac 上才有的命令。如果你的服务器是 Linux，签名步骤需要改用zsign或isign这类开源工具，具体见第 4 章。注意脚本中省略了证书的 keychain 导入和环境变量设置，这些需要在执行签名前处理。还有一点容易忽略：embedded.mobileprovision必须与证书匹配，否则签名后安装时会报“无法验证App”的错误。
3. PHP 7.4 + MySQL 5.6 环境下的部署与踩坑记录
3.1 数据库初始化与 config.php 的配置要点
这套系统在 Nginx + PHP 7.4 + MySQL 5.6 环境下设计，数据库结构需要手动导入。源码包中一般附带一个.sql文件，如果没找到，可以从 PHP 代码里反向推导需要哪些表：通常有 apps、sign_codes、devices、orders 等。最少需要三张表：apps 存储软件信息，sign_codes 存储签名码，devices 记录 UDID。
建表 SQL 示例：
CREATE TABLE `apps` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(100) NOT NULL, `file_name` varchar(255) NOT NULL, `bundle_id` varchar(100) NOT NULL, `version` varchar(20) NOT NULL, `icon` varchar(255) DEFAULT NULL, `status` tinyint(1) DEFAULT '1', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `sign_codes` ( `id` int(11) NOT NULL AUTO_INCREMENT, `code` varchar(64) NOT NULL, `status` tinyint(1) DEFAULT '0', `created_at` datetime DEFAULT CURRENT_TIMESTAMP, `used_at` datetime DEFAULT NULL, `device_udid` varchar(64) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `code` (`code`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;config.php 中需要配置数据库连接和上传目录：
define('DB_HOST', '127.0.0.1'); define('DB_NAME', 'sign_system'); define('DB_USER', 'root'); define('DB_PASS', 'yourpassword'); define('IPA_UPLOAD_DIR', '/data/ipa/'); define('SIGNED_OUTPUT_DIR', '/data/signed/'); define('BASE_URL', 'https://yourdomain.com');注意BASE_URL结尾不要带斜杠，否则拼接下载地址时容易出现双斜杠。MySQL 5.6 对 utf8mb4 的索引长度有 767 字节限制，如果code字段长度超过 191 个字符，建立唯一索引会失败，所以签名码字段建议控制在 64 字符内。如果你的 MySQL 是 5.6 但编译时没有开启 innodb_large_prefix，上面的 64 字符也没问题。
3.2 Nginx 关键配置：防止 PHP 文件被下载
使用 Nginx 时一个常见问题是 PHP 文件被直接当作静态文件下载，这通常是因为 fastcgi 配置缺失或location块没写好。一个经过验证的最小配置如下：
server { listen 443 ssl; server_name yourdomain.com; ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; root /var/www/sign_system; index index.html index.php; location / { try_files $uri $uri/ =404; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php7.4-fpm.sock; } location ~* \.(ipa|mobileprovision)$ { root /data; add_header Content-Disposition 'attachment'; } }try_files的=404结尾很重要，如果去掉了，当请求一个不存在的 PHP 文件时，Nginx 会 fallback 到 index.html，导致前端请求返回 200 但内容是 HTML，JavaScript 解析后一脸懵。location ~* \.(ipa|mobileprovision)$用来直接放行签名产物和描述文件的下载，否则会被 PHP 解析或返回 404。另一个坑是fastcgi_pass如果配成了127.0.0.1:9000，记得确认 PHP-FPM 是否在那个端口监听，否则会出现 502。
3.3 PHP 7.4 对旧代码的兼容性处理
因为源码来自开源社区，很可能基于 PHP 5.x 或 7.0 编写，直接跑在 7.4 上会有废弃语法问题。最常见的三处：mysql_*函数已移除、each()函数已移除、花括号字符串偏移语法不再支持。检查一下代码里有没有mysql_query、mysql_fetch_array，如果有，需要改成 PDO 或 mysqli。例如：
// 旧写法 $link = mysql_connect('localhost', 'user', 'pass'); mysql_select_db('sign_system', $link); $res = mysql_query("SELECT * FROM apps", $link); // 7.4 兼容写法 $pdo = new PDO('mysql:host=127.0.0.1;dbname=sign_system', 'user', 'pass'); $stmt = $pdo->query("SELECT * FROM apps"); $apps = $stmt->fetchAll(PDO::FETCH_ASSOC);如果原始代码里有ereg、split等函数，也要换成正则preg_match或explode。还有一个隐藏问题：PHP 7.4 中对implode()的参数顺序做了规范化，旧代码里implode($array, ',')会报参数错误，需要改成implode(',', $array)。这些兼容问题在 config、edit 页面的表单处理部分最常见，建议部署时打开 PHP 错误日志，把display_errors设为 Off，日志级别调到 E_ALL，逐个修正。
4. 签名核心实现：从命令行工具到证书管理
4.1 为什么服务器端签名不能直接依赖 Xcode
如果你想把这套系统跑在 Linux 服务器上，codesign是不存在的。Xcode 的 codesign 仅存在于 macOS 环境，而大多数站长购入的云服务器是 CentOS 或 Ubuntu。这时有两种路径：一是用 macOS 作为签名机，通过远程调用执行签名；二是在 Linux 上使用开源签名工具，例如zsign。zsign 是一个用 C++ 实现的跨平台 IPA 签名工具，支持 p12 证书和 mobileprovision 描述文件，命令格式比 codesign 简单得多。
zsign 的基本用法：
zsign -k cert.p12 -p 证书密码 -m profile.mobileprovision -o output.ipa input.ipa其中-k指定私钥证书 p12 文件，-p是私钥密码，如果 p12 没有密码可以省略-p参数，-m指定描述文件，-o指定输出 IPA 路径，最后一个参数是待签名的输入 IPA。zsign 也会自动修改 Info.plist，但如果你想改 Bundle ID 为多开做准备，需要先用-b参数指定新的 Bundle ID：
zsign -k cert.p12 -p 123456 -m profile.mobileprovision -b com.example.app.dup1 -o output.ipa input.ipa这里有个使用细节：-b参数不是所有旧版本 zsign 都支持，建议自己 clone 最新源码编译。编译依赖需要 openssl 和 zlib，在 Ubuntu 上可以用apt install libssl-dev zlib1g-dev安装，然后执行：
git clone https://github.com/zhlynn/zsign.git cd zsign make编译成功后会在当前目录生成zsign可执行文件，把它放到/usr/local/bin/下。zsign 不校验证书是否与描述文件匹配，它只是机械地把 description 内的证书嵌入签名结构，所以如果传入了不匹配的 p12 与 mobileprovision，签名过程不会报错，但安装时会失败。建议在每次上传证书后，先用zsign -d profile.mobileprovision查看描述文件里的证书信息，和 p12 里的证书比对一次。
4.2 描述文件、证书、Bundle ID 三者的匹配关系
在线签名系统最容易出错的地方不是代码，而是证书匹配逻辑。一个可安装的 IPA 需要满足三个条件：描述文件中记录的 AppID 与 IPA 的 Bundle ID 匹配；描述文件中包含的证书与 p12 私钥对应；证书与描述文件的 Team ID 一致。系统后台如果支持多套证书，那么配置表中要记录每个 App 使用哪一套证书。
建议在数据库里加一张证书表：
CREATE TABLE `certs` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(64) NOT NULL, `p12_path` varchar(255) NOT NULL, `p12_password` varchar(128) DEFAULT NULL, `mobileprovision_path` varchar(255) NOT NULL, `team_id` varchar(32) NOT NULL, `bundle_ids` text, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;bundle_ids可以存允许签名的 App Bundle ID 列表，用逗号分隔，这样在签名前可以先比对。要获取描述文件中的信息，可以执行：
security cms -D -i profile.mobileprovision这是 macOS 的命令，在 Linux 上可以使用openssl smime -inform DER -verify -noverify -in profile.mobileprovision输出 XML 内容，然后 grep 出bundle-identifier和TeamIdentifier。我在实践中更喜欢写一个小 PHP 脚本来读取描述文件：
$content = file_get_contents($profilePath); // embedded.mobileprovision 是一个 DER 编码的 CMS 签名 // 简单处理是直接搜索字符串 preg_match('/<key>application-identifier<\/key>\s*<string>([^<]+)<\/string>/', $content, $m); $appId = trim($m[1] ?? '');这个方式有点粗暴，但足够快。正式环境中最好用 openssl 命令把 CMS 解码后再解析，避免误匹配字段。注意描述文件里的application-identifier是TEAMID.com.example.app格式，而 Info.plist 里的CFBundleIdentifier只有com.example.app，比对时要去掉前缀再比较，否则会误判为不匹配。
4.3 多开安装的实现原理与 plist 修改
多开 APP 安装是本系统的亮点，技术核心是修改 IPA 中的 Bundle ID，并重新签名。因为 iOS 系统通过 Bundle ID 区分应用实例，同一台设备上不能安装两个相同 Bundle ID 的应用，改掉就能骗过系统。
修改 Info.plist 的常见做法是使用 PlistBuddy，这是 macOS 自带的工具：
/usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier com.example.app.dup1" Payload/xxx.app/Info.plistLinux 下没有 PlistBuddy，可以使用plutil或者直接用 PHP 修改：
function changeBundleId($plistPath, $oldBundleId, $newBundleId) { $plist = file_get_contents($plistPath); $plist = str_replace($oldBundleId, $newBundleId, $plist); file_put_contents($plistPath, $plist); }注意：简单的字符串替换有风险，因为一个 plist 中可能多处出现旧 Bundle ID，例如CFBundleURLSchemes里也有 app scheme，如果 scheme 也一起被替换，可能导致应用内跳转异常。通常只需要替换CFBundleIdentifier和CFBundleName（显示名称），而 URL Scheme 保留原样更安全。因此不要用全局替换，而是先解析 plist 为数组，再单独修改键值。
PHP 解析 plist 可以借助CFPropertyList库或执行系统命令。如果服务器是 macOS，直接调 PlistBuddy 最省事。多开后，如果应用本身有推送、支付等依赖 Bundle ID 的配置，可能会出现收不到推送或支付回调失败的情况，这是业务层面要接受的代价。
还有一个细节：重签名后 IPA 包的 Size 会略有变化，如果下载时前端记录了旧文件大小做完整性校验，就会失败。所以签名完成后要重新计算 MD5 并更新数据库字段，或者干脆不做文件大小校验。
5. 签名码生成策略与 UDID 绑定的实战玩法
5.1 签名码的生成算法与存储设计
签名码功能不只是“输入一串码就能签名”，它还要避免被刷、避免一码多用、避免伪造。合理的签名码应该包含时间和随机因子，且后端要登记生成记录。示例生成函数：
function generateSignCode($length = 16) { $characters = 'ABCDEFGHJKLMNPQRSTUVWXYZ23456789'; $code = ''; for ($i = 0; $i < $length; $i++) { $code .= $characters[random_int(0, strlen($characters) - 1)]; } return $code; }这里刻意去掉了容易混淆的I、O、0、1。生成后插入 sign_codes 表，状态为 0。当用户提交签名码时，后端执行一次事务：先查状态、再更新状态为 1、记录使用时间。如果不加事务，并发请求下同一个签名码可能被多次使用，造成签名资源被滥用。
事务写法：
$pdo->beginTransaction(); $stmt = $pdo->prepare("SELECT * FROM sign_codes WHERE code = ? FOR UPDATE"); $stmt->execute([$code]); $row = $stmt->fetch(); if (!$row || $row['status'] != 0) { $pdo->rollBack(); exit('签名码无效'); } $pdo->prepare("UPDATE sign_codes SET status = 1, used_at = NOW(), device_udid = ? WHERE id = ?") ->execute([$udid, $row['id']]); $pdo->commit();SELECT ... FOR UPDATE是 MySQL 5.6 中行锁的常用手段，配合事务保证同一时间只有一个请求能消费这个码。如果你用的存储引擎是 MyISAM（不推荐），FOR UPDATE 不会生效，需要换成表锁。默认引擎应该是 InnoDB，前提是建表时没有指定其他引擎。
如果不想让用户拿一个签名码给任意设备签名，可以在校验时加入 UDID 绑定逻辑：签名码生成时如果绑定了 UDID，那么 sign.php 中要校验传入的 UDID 与表中记录一致。绑定的时机通常是用户先获取 UDID，再输入签名码提交。也有的系统是签名码本身包含 UDID 信息，比如UDID的后 8 位加上随机码，这样即使码被截图也换不了设备，但缺点是码长度长，体验不好。我建议使用存储绑定，而不是码内编码，灵活度高且易于后台管理。
5.2 与 UDID 回流联动：签名流程的完整状态机
把 UDID 和签名码联系起来后，整个流程就清晰了。用户在 Safari 打开描述文件 → install.php 拿到 UDID → 重定向到签名页并自动填充 UDID → 用户选择 App 输入签名码 → sign.php 校验并签名。这个状态机的关键点是签名页要能识别“UDID 已获取”和“UDID 未获取”两种状态，否则用户直接访问签名页时会卡住。
一个简单的状态标记可以用 Cookie 或 URL 参数。install.php 重定向时带上?udid=xxx，签名页 JavaScript 读取参数后放入隐藏字段：
function getQueryParam(name) { const params = new URLSearchParams(window.location.search); return params.get(name); } const udid = getQueryParam('udid'); if (udid) { document.getElementById('udid_input').value = udid; } else { document.getElementById('udid_input').value = ''; }如果检测不到 UDID，页面可以提示用户先点击“获取 UDID”按钮。这个按钮的 href 指向描述文件下载路径。描述文件下载路径最好是通过 PHP 动态输出的，设置 Content-Type 为application/x-apple-aspen-config，这样浏览器不会直接下载而是弹出安装描述文件的提示。Nginx 也可以直接配置，但用 PHP 输出可以顺便记录访问日志，方便分析有多少人卡在描述文件安装环节。
5.3 常见失败：签名失败、描述文件失效的排查路径
签名失败是一个很大的话题，按经验分成三类：证书问题、权限问题、代码问题。证书问题包括证书过期、证书与描述文件不匹配、p12 密码错误。权限问题包括服务器上 zsign 没有执行权限、IPA 目录不可写、临时目录空间不足。代码问题则是你修改 plist 时破坏了 plist 结构，导致签名工具无法解析。
如果你用的是 macOS + codesign，签名失败时可以看到明确报错。如果报User interaction is not allowed，说明 codesign 试图访问 keychain 但没有解锁权限，这时需要执行：
security unlock-keychain -p yourpassword login.keychain这是 macOS 签名机上最常见的坑。如果使用 zsign，报错通常较少，一旦签名成功但安装失败，几乎可以断定是描述文件或证书的问题。在 iOS 设备上安装时提示“无法安装 App，因为证书无效”，马上用openssl smime查看描述文件中的证书序列号是否与 p12 一致。
还有一种隐蔽情况：描述文件里的 ProvisionedDevices 列表不包含当前这台设备的 UDID。企业证书的描述文件通常不带设备限制，但开发证书的描述文件会限制设备 UDID。如果用户反映“只有我的设备装不上”，先查看描述文件的类型。Android 用户可以忽略这一条，但 iOS 分发必须区分 Development 与 Distribution 描述文件，后者又分为 Ad Hoc 和 App Store 类型。这套系统要做的在线签名，通常使用的是 Ad Hoc 或企业证书，App Store 类型的描述文件无法直接用于 IPA 安装。
6. 用日志和压力测试验证整套系统是否真的可靠
6.1 日志埋点与状态文件设计
线上系统不能靠“感觉”。我建议在关键节点写入结构化日志，而不是在页面里echo调试。至少要在以下位置打点：描述文件下载时、install.php 收到 POST 时、签名码校验成功/失败时、签名命令执行完毕时、最终下载链接生成时。日志格式统一为 JSON，方便后续用 jq 或 Python 分析。
{"type":"udid_received","time":1710000000,"udid":"00008020-000A","ip":"1.2.3.4"}function writeLog($type, $data) { $log = json_encode(['type' => $type, 'time' => time(), 'data' => $data]); file_put_contents('/var/log/sign_system.log', $log . PHP_EOL, FILE_APPEND); }为了快速定位签名失败，可以在 sign.php 中把签名命令的 stdout 和 stderr 都写入日志。PHP 的exec只能拿到最后一行输出，建议使用proc_open或者把命令重定向到文件：
exec("zsign -k cert.p12 -p pass -m profile.mobileprovision -o output.ipa input.ipa 2>&1 >> /var/log/sign.log");这样签名工具自身的报错会进入日志。初次部署时，可以先手动在服务器上执行一遍同样的命令，确认能成功后再让 PHP 调用，排除掉权限和路径问题。
6.2 模拟并发签名请求的信号量限制
在线签名系统在高并发时容易崩溃，因为签名是 CPU 密集任务。如果同时有 20 个用户提交签名请求，而服务器又只有 2 核，每个签名任务还会创建临时目录、读写大文件，服务器很容易被拖垮。常见做法是对签名任务加锁，同一时间只允许 N 个签名进程运行。
PHP 中可以用flock实现简单的进程锁：
$lockFile = '/tmp/sign_process.lock'; $fp = fopen($lockFile, 'w'); if (!flock($fp, LOCK_EX | LOCK_NB)) { exit('当前签名任务较多，请稍后再试'); } // 执行签名... flock($fp, LOCK_UN); fclose($fp);这个锁是全局锁，只能串行。如果想保留 2 个并发名额，可以用信号量扩展sysvsem，或者用一个基于 Redis 的计数器。更简单粗暴一些：直接用 MySQL 的GET_LOCK函数：
$pdo->query("SELECT GET_LOCK('sign_slot', 0)"); if ($pdo->query("SELECT IS_USED_LOCK('sign_slot')")->fetchColumn()) { exit('系统繁忙'); }这只适合单机部署，多机部署时需要引入队列。考虑到这套源码的定位，单体 PHP 系统加上flock或 MySQL 锁已经足够。压力测试时可以用ab或wrk对 install.php 和 sign.php 进行 POST 请求模拟，观察响应时间和系统负载，如果发现 CPU 被打满，优先检查是否同时解压了过多 IPA 而没有清理临时目录，/tmp写满的情况很容易被忽略。
6.3 验签脚本：签完的 IPA 能不能装
最后一步是验证签名结果。手动测试一台真机成本高，可以先在服务器上用工具校验签名结构。zsign 提供-d参数对 IPA 进行完整校验：
zsign -d output.ipa如果输出中没有error，说明签名结构完整。进一步校验 Bundle ID 是否被修改成预期值：
unzip -p output.ipa Payload/*.app/Info.plist | plutil -p - | grep CFBundleIdentifierLinux 没有 plutil 也可以用 python3 的 plistlib：
unzip -p output.ipa 'Payload/*.app/Info.plist' | python3 -c "import plistlib,sys; d=plistlib.load(sys.stdin.buffer); print(d['CFBundleIdentifier'])"将输出与签名码绑定的目标 App 记录比对，若不一致，说明多开或编辑流程中 plist 修改失效。另一个验证项是描述文件中的 Application Identifier 是否和新的 Bundle ID 前缀兼容：如果描述文件通配符是TEAMID.*，则任何 Bundle ID 都能通过；如果是TEAMID.com.example.app，那多开修改后的com.example.app.dup1与描述文件不匹配，安装会失败。这一点在后台配置证书时就要按Bundle IDs列里实际填写的通配范围区分提示，避免用户花了时间签名却得到不可安装的产物。
这套系统真正的可靠标准不是“签名命令有没有执行成功”，而是最终 IPA 能否在一个全新未越狱设备上静默安装成功。装上以后打开一次不闪退，才说明签名码、描述文件、证书、Bundle ID 四个环节全部对齐。至此，整条链路从 UDID 获取到多开安装就全部打通了，剩下的事情就是把你自己的证书和 App 列表导入后台，让用户开始发起签名请求。
本文还有配套的精品资源，点击获取
