简介面向需要搭建自有应用分发平台的开发者与企业此资源提供APP2025分发系统完整源码通过免签封装与自动签名机制覆盖安卓APK、苹果iOS及Windows EXE分发省去繁琐证书配置适合作为私有化应用商店或内部分发系统的技术底座。包体共191个文件约75.07MB核心包括PHP后端、前端管理页面CSS/JS、签名与加固工具JAR/SO/DLL/EXE及数据库SQL和JKS证书配置模块划分清晰便于直接部署或二次开发。系统还内置一次性下载码、iOS描述文件mobileconfig/plist处理与服务器端自动签名脚本显著降低跨平台分发门槛。资源已有80人学习下载包含完整项目文件与构建脚本可直接参考免签封装和签名验证流程用于搭建安全可控的分发通道。1. 源码免签分发的真实场景2025年为什么还要本地部署一套分发后台都2025年了上架通道看着多但真正做内测分发的人都知道装包发不到用户手里才是常态。这套APP2025分发系统源码解决的就是这个具体问题一套PHP后台同时管安卓APK、苹果IPA和Windows EXE三种格式的分发标题里的“免签封装”在苹果侧是UDID描述文件采集那套流程在安卓侧是直接分发已签名安装包、省掉重复打包在EXE侧是版本检测与下载页生成。适合谁呢上架安卓应用市场还要软著和备案的团队被TestFlight审核排队折腾过的开发者以及吃过企业证书被吊销亏的人。它不解决打包解决的是“包好了怎么发出去、怎么统计、怎么更新”这条链路。2. 系统架构与目录落地PHP后台、MySQL表结构与两小时部署2.1 源码目录结构与核心文件职责我拿到源码的习惯是先把目录结构摸一遍判断这套系统是哪类技术栈。这套是经典PHP结构Nginx PHP 7.4 MySQL 5.7就能跑不需要Composer依赖不需要Node环境放到虚拟主机也能转。这也是这类分发系统一直用PHP的原因——运维成本低换服务器迁移方便。路径职责部署时要注意的install/安装向导与install.sql装完记得整个目录删掉config/数据库、站点配置数据库密码写在这里public/前台入口index.phpNginx的root指到这一层application/admin/后台管理应用、链接、统计登录入口默认是admin路径application/api/对外接口下载、UDID、版本检测需要确认站点URL配好upload/APK/IPA/EXE文件存放给755权限别给可执行权限runtime/缓存与日志权限不足会白屏几条判断经验可以分享。PHP版本别一上来就上8.3这类源码多数在7.x上写的部分函数在8.x报弃用警告轻则日志刷屏重则后台某个页面直接白屏。我一般固定PHP 7.4这套源码里唯一要开的扩展是pdo_mysql和fileinfo前者连库后者校验上传文件的MIME类型。2.2 LNMP部署步骤与关键参数部署流程完全往下走正常是两小时以内。第一步把压缩包解到站点目录第二步改配置第三步导入数据库第四步配Nginx伪静态。unzip APP2025分发系统源码免签封装支持安卓和苹果及EXE程序分发.zip -d /www/wwwroot/app2025 cd /www/wwwroot/app2025 cp config/database.example.php config/database.php vim config/database.phpconfig/database.php里要改的是三个值数据库地址默认127.0.0.1不用动、库名、账号密码。注意密码里如果有特殊字符比如#和$PHP字符串里要转义我就见过有人密码带#导致PDO连接串被截断后台一打开就报数据库错误。mysql -uroot -p app2025 install/install.sql导入数据库这一步有个细节用phpMyAdmin导入大SQL容易半路超时命令行导入最稳。如果服务器上只有phpMyAdmin可用提前把max_execution_time和upload_max_filesize调大否则install.sql的注释行一多就导入不完整后面后台点应用列表直接报表不存在。Nginx伪静态是这套系统能不能正常出页面的关键配置如下。server { listen 80; server_name dist.example.com; root /www/wwwroot/app2025/public; index index.php index.html; location / { if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?s$1 last; } } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location /upload/ { expires 7d; add_header Cache-Control public; } }参数说明root指到public而不是项目根目录是为了防止用户直接访问config/database.php这种敏感文件fastcgi_param的SCRIPT_FILENAME动态拼接避免用fastcgi_pass unix socket但路径写死导致404/upload/单独加7天缓存应用包重复下载时能省带宽但要注意更新版本时文件名必须不同否则CDN和浏览器缓存会让用户拿到旧包。安装完成后浏览器访问http://你的域名/install/按向导填数据库配置和后台管理员账号。建议首次登录后台就把默认管理员密码换掉这类系统历史上很多被扫后台弱口令的案例。部署完第一次创建应用时后台必填参数一般是这五个应用名称、包名或Bundle ID、平台、版本号、更新日志外加一个强制更新开关。参数填写示例说明应用名称示例办公展示在下载页和安装提示里包名/Bundle IDcom.example.app苹果plist必须与IPA实际值一致平台android / ios / exe决定走哪套分发逻辑版本号1.2.0建议三段式不要写1.2强制更新是/否为true时客户端不能跳过更新2.3 数据表结构与后台功能对应关系这套系统的核心表我整理成了一张表后台每个功能基本都能对应到一张表。表名核心字段对应的后台功能app_listapp_id, app_name, bundle_id, version, update_log, force_update应用管理app_linklink_id, app_id, platform, file_path, file_md5, download_count分发链接管理download_logid, link_id, ip, ua, day下载统计udid_logid, udid, product, version, create_time苹果UDID采集记录admin_userid, username, password后台账号bundle_id这个字段在三个平台里实际存的东西不一样安卓存APK的包名com.example.app苹果存IPA的Bundle Identifier同样是com.example.app但签名机制不同EXE存的是0或空。它在系统里有两个用途一是苹果装包时plist里必须和IPA实际Bundle ID一致二是安卓做升级匹配时用来认应用。我建议建应用时就严格区分别把安卓包名和苹果Bundle ID混写后面升级接口按同一个bundle_id做多平台匹配时才能统一。3. 免签封装三平台实现参数APK签名、UDID描述文件与EXE更新接口源码标题里“免签封装”四个字最容易让人误解。实际操作里三个平台的处理逻辑完全不同我拆开讲。3.1 安卓侧原包直传与渠道标识参数安卓不存在真正意义上的免签任何APK要装上Android 7的设备就必须有V1/V2签名Android 11以上强制要求V2。所以这套源码在安卓侧做的是另一件事不重新签名直接分发你上传的已签名APK把“签名”这个动作留给打包机。这样做的直接好处是——你用公司key签的包外发后签名不会被破坏后续能正常升级坏处是——它解决不了包本身被风险引擎标记的问题如果你的APK权限敏感装的时候该拦截还是拦截。后台处理APK上传的核心逻辑如下。// application/admin/upload_apk.php $app_id intval($_POST[app_id] ?? 0); $file $_FILES[apk] ?? null; if (!$file || $file[error] ! UPLOAD_ERR_OK) { exit(json_encode([code 1, msg 上传失败])); } $ext strtolower(pathinfo($file[name], PATHINFO_EXTENSION)); if ($ext ! apk) { exit(json_encode([code 1, msg 仅支持APK文件])); } $save_name date(Ymd) . _ . md5(uniqid()) . .apk; $save_path ROOT_PATH . upload/apk/ . $save_name; if (!move_uploaded_file($file[tmp_name], $save_path)) { exit(json_encode([code 1, msg 写入upload目录失败])); } $link_id $db-insert(app_link, [ app_id $app_id, platform android, file_path /upload/apk/ . $save_name, file_md5 md5_file($save_path), create_time time() ]); if ($link_id) { echo json_encode([code 0, link_id $link_id]); }逻辑说明上传文件先检查error值而不是只查扩展名很多人会漏这一步结果空文件被写入保存文件名用日期加随机串不让用户原始文件名进服务器避免路径穿越和同名覆盖file_md5存的是整个APK文件的MD5这个值后续可以用来做下载校验也能防止后台重复上传同一个包。参数说明link_id是这条分发链接的唯一标识推广链接里带着它比如https://dist.example.com/down?link_id27后台下载统计就是按它聚合的。渠道埋点就是这么做的——不同渠道给不同的link_id后台直接看趋势就能知道哪个渠道转化好。安卓用户点击下载后还有一层“未知来源”的引导Android 8以上首次安装外部APK系统会强制用户去设置里打开“允许来自此来源的应用”。分发系统的下载页模板里一般会放一段图文引导没有的话就自己做个静态页写清楚三步点下载、设置里放行、回页面再点一次。这一步不做大量小白用户会卡在系统弹窗上。3.2 苹果侧UDID采集描述文件与itms-services安装plist苹果侧才是“免签”真正有意义的地方。不上TestFlight、不进App Store靠描述文件采集UDID 托管IPA itms-services协议让用户直接用Safari装包。完整流程三步用户访问采集页装描述文件系统拿到UDID后为这个设备生成安装页用户再点itms-services链接装IPA。这套链路里描述文件是入口也是第一个容易出问题的环节。描述文件本质是一个XML plistPayloadType必须是Profile Service配置如下。?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 keyPayloadContent/key dict keyURL/key stringhttps://dist.example.com/api/udid.php/string keyDeviceAttributes/key array stringUDID/string stringProduct/string stringVersion/string /array /dict keyPayloadOrganization/key stringExample Inc./string keyPayloadDisplayName/key string安装前设备绑定/string keyPayloadIdentifier/key stringcom.example.profile.udid/string keyPayloadType/key stringProfile Service/string keyPayloadUUID/key string9B28F6B4-1A2B-4C3D-9E4F-5A6B7C8D9E0F/string keyPayloadVersion/key integer1/integer /dict /plist参数说明URL回调地址必须全站HTTPS苹果设备装描述文件时如果不是HTTPS会直接提示描述文件未签名并拒绝PayloadIdentifier和PayloadUUID保持固定不要每次访问都重新生成否则同一个设备每次都是“新描述文件”体验上是装一次多一个描述文件DeviceAttributes里不用写IMEI——从iOS 7开始IMEI就不给普通描述文件读了写了也白写UDID和Product才是真能拿到的。拿到UDID之后系统要做的事是生成安装用的plist也就是itms-services链接指向的那份manifest。?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://dist.example.com/upload/ipa/app_1.2.0.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安装页上的链接写法固定是itms-services://?actiondownload-manifesturl这份plist的https地址。这一环有三条铁律软件包url和plist地址都必须httpsbundle-identifier必须和IPA里实际的值一字不差用解包工具看Info.plist不要凭记忆填bundle-version推荐和实际版本保持一致否则部分iOS版本安装后设置里显示的版本号会误导你排查问题。3.3 EXE侧版本检测接口与静默更新参数EXE分发本质上只有两件事上传EXE生成下载链接提供一个版本查询接口让客户端自检更新。接口返回JSON客户端拿到新版本地址后自行下载替换。// application/api/check_update.php header(Content-Type: application/json); $app_id intval($_GET[app_id] ?? 0); $client_ver trim($_GET[version] ?? 0.0.0); $app $db-queryOne( SELECT version, exe_url, update_log, force_update FROM app_list WHERE id {$app_id} ); if (!$app) { exit(json_encode([code 2, msg 应用不存在])); } if (version_compare($client_ver, $app[version], )) { exit(json_encode([ code 1, update true, url $app[exe_url], log $app[update_log], force intval($app[force_update]) 1 ])); } exit(json_encode([code 0, update false]));逻辑说明用version_compare而不是字符串比较因为字符串比较下1.9会大于1.10这是很多人忽略的坑force字段就是给客户端“强制更新”用的true时客户端弹窗不给关闭false时允许“稍后再说”exe_url一定要返完整URL而不是相对路径客户端不一定和你同域名。参数说明客户端带version参数来查服务端只做比较和返回不做身份校验。如果担心接口被刷可以在后台配置一个token客户端请求时带上tokenxxxx虽然治标不治本但能挡掉大部分扫描器。老版本的EXE文件建议后台保留最近两三个就够了EXE体积通常比APK还大全部堆在upload目录里磁盘很快就满。4. 分发系统避坑指南安装失败、UDID丢失与下载统计虚高的排错记录这套系统跑起来不难但真正让你半夜起来改配置的永远是那几个边缘场景。我把反复踩的坑按“现象 → 原因 → 解决”整理出来。4.1 三条高频翻车拦截、99%报错、版本不更新坑一安卓用户点下载浏览器和手机管家直接弹“风险应用”有些机型直接说是“检测到病毒”。现象是同一个APK在微信里发没有人拦挂到分发页上就被拦。原因一般是两条线一是下载域名没有备案或者说域名刚注册不久被风险引擎标了低信誉二是APK本身权限太敏感定位、通讯录、短信权限全申请特征库直接命中。解决方式是分两步走域名提前养用老域名或者做域名备案加HTTPSAPK权限收敛把非核心功能需要的权限从清单里摘掉重新签一发。权限这个事没有后悔药发出去的包权限越敏感后续被标记的概率越高。坑二苹果用户点itms-services链接下载到99%弹出“无法安装应用”。现象是进度条走满最后一步秒退。原因九成是manifest里的bundle-identifier和IPA实际值不一致剩下的一成是软件包url不是https或者IPA本身签名已被吊销。解决方法是先解包核对把IPA后缀改zip解压取Payload/xxx.app/Info.plist用plutil或任何plist阅读器看CFBundleIdentifier实际值再把manifest里的值改成一致。企业签名的包还要确认证书没过期苹果近几年对企业证书的吊销动作更频繁了吊销后manifest怎么改都没用只能重新签一个新的。坑三新版本后台传了客户端版本号没变升级接口返回“已是最新”。现象是客户端反复调用接口都拿不到新版本。原因大多数不是接口问题是后台“应用版本号”字段里写了错误版本——我见过有人把安卓渠道的version填成1.10客户端报1.9按字符串比较1.9 1.10走不到更新分支。解决是把比较逻辑统一成version_compare并且建应用时规定版本号一律三段式1.2.0别用两位数这条规矩能从源头杜绝大多数比较问题。4.2 两条后台数据问题UDID收不到、下载量虚高坑四用户描述文件装了后台udid_log表一条都没有。现象是Safari提示描述文件已安装但系统回调URL没有记录。原因八成是描述文件里URL字段用的http苹果OS版本高了之后直接在回调阶段拦截还有两成可能是PayloadType写错或URL路径和api/udid.php不匹配。解决是把回调URL改https并在api/udid.php日志里临时加一行file_put_contents(/tmp/udid_debug.log, json_encode($_GET), FILE_APPEND)装完描述文件立刻看日志有参数说明回调通了没参数说明描述文件配置问题更大。这个临时日志排查完记得删掉。坑五下载统计虚高一天涨几千实际装机量两三百。现象是后台download_log每天大量记录装机对不上。原因是统计逻辑放在了下载页的onclick事件里爬虫、预加载、手滑点击都会被记成一次。解决是改服务端302重定向统计把onclick统计撤掉下载链接统一走api/download.php按“IP link_id 当天日期”去重后再计数。这样百度爬虫抓一次也不会污染数据用户刷新十次也只算一次。5. 下载页与更新策略改造UA分流、多线路切换与强制更新参数源码自带的下载页能用但直接上线容易被挑刺——我指的不是好看不好看是分流逻辑和真实用户场景不匹配。5.1 下载页改造UA三分流与二维码引入默认下载页通常是一个页面放三个平台的下载按钮用户得自己判断点哪个。实际运营里同一个链接要发到微信群和公众号菜单里用户手机类型千差万别最可靠的做法是服务端按UA直接分流。// public/down.php $link_id intval($_GET[link_id] ?? 0); $ua $_SERVER[HTTP_USER_AGENT]; if (stripos($ua, iPhone) ! false || stripos($ua, iPad) ! false) { // iOS先进UDID采集页再进安装指引 header(Location: /udid?link_id . $link_id); exit; } if (stripos($ua, Android) ! false) { // 安卓直接302到下载接口服务端计一次有效点击 header(Location: /api/download.php?link_id . $link_id . platformandroid); exit; } // PC展示EXE下载页包含版本和更新日志 header(Location: /page/exe?link_id . $link_id); exit;逻辑说明这个脚本要放在public下直接被访问不走应用路由因为前面伪静态规则里静态文件优先匹配响应最快。iPhone和iPad归到同一分支因为iPadOS的Safari同样支持itms-services协议。安卓直接302到下载接口把统计埋点和服务端重定向合并成一步比页面里放JS统计可靠得多。参数说明link_id从URL取到后贯穿三个平台iOS分支进入采集页时也要带上它否则采集完UDID回不到这个应用的安装页。另一个细节是Android的分流不要只认Android关键字部分国产浏览器的UA会把Android写成Mozilla/5.0 (Linux; U; Android 12; zh-cn)这种带语言尾标的变体stripos不区分大小写匹配Android就能覆盖大部分情况。二维码的引入在小屏场景里很有用。PC页面里把当前下载链接生成二维码用户手机扫码直接走上面的UA分流不用在电脑和手机之间来回传文件。生成方式用现成的PHP二维码库或者第三方接口都行核心是把当前页完整URL传进去注意URL必须是https否则手机扫码后Safari打开描述文件页会被拦。多线路切换这块我一般会在后台给每个应用加一个备用下载地址字段。主链路走的是服务器本地upload目录备用链路指向对象存储或者CDN。判断逻辑可以很朴素服务端下载接口先探测主文件在不在不在就直接302到备用地址。这样即使服务器磁盘满了或者文件被误删用户点下载不会得到一个404页。5.2 更新策略强制更新、灰度放量与下载去重统计下载统计这块源码默认逻辑各有差异我按自己的习惯改造成了这样服务端先记录再跳转真实文件并且同IP同日同一链接只记一次。// application/api/download.php $link_id intval($_GET[link_id] ?? 0); $ip $_SERVER[REMOTE_ADDR]; $ua $_SERVER[HTTP_USER_AGENT]; $today date(Ymd); $dup $db-queryOne( SELECT id FROM download_log WHERE link_id {$link_id} AND ip {$ip} AND day {$today} ); if (!$dup) { $db-insert(download_log, [ link_id $link_id, ip $ip, ua $ua, day $today, ]); $db-execute( UPDATE app_link SET download_count download_count 1 WHERE id {$link_id} ); } $link $db-queryOne(SELECT file_path FROM app_link WHERE id {$link_id}); header(Location: . $link[file_path]);逻辑说明IP link_id 日期这个组合去重能挡住同一个人反复刷新下载页刷量的情况但拦不住多IP刷量要更严可以加Cookie校验。注意这里只记录下载行为如果追求“完成安装”这个更精确的指标安卓侧需要你的APK里自己上报装机事件分发系统本身做不到。参数说明link_id在SQL里直接intval过不会产生注入ip字段存的是REMOTE_ADDR如果前面挂了CDN或负载均衡这个值会变成CDN节点IP需要在Nginx里把真实IP透传配置好否则所有下载都来自同一个IP去重直接失效。灰度放量的做法我一般会在app_list表加一个release_ratio字段0-100下载分发时按随机数决定给不给新版包。默认值建议先给10观察崩溃上报正常再逐步提到50、100。比例判断代码放在download.php跳转之前$app $db-queryOne(SELECT release_ratio FROM app_list WHERE id . intval($app_id)); if (rand(1, 100) $app[release_ratio]) { // 走旧版本包地址 header(Location: . $app[old_file_path]); } else { header(Location: . $app[file_path]); }说明一下rand取模在流量小时会有波动10%的比例可能在某个时段一单都没有这是概率方法本身的特性不是系统bug。如果业务上必须精确到单就需要在后台把灰度名单导出来做白名单匹配那就超出分发系统的默认能力范围了。6. 上线自检清单域名HTTPS、签名校验与三个平台预演这套系统我交付过几次每次上线前都会逼自己走一遍完整自检顺序不能乱我列成清单。检查项验证方法不通过的后果全站HTTPS浏览器访问下载页确认地址栏锁标描述文件无法回调itms-services无法安装域名备案与风险信誉用手机管家和浏览器扫自己的下载域名安卓下载被风险引擎拦截APK签名完整性用apksigner verify核对APK签名Android 11直接拒绝安装IPA的Bundle ID解包看Info.plist与manifest对比iOS安装到99%失败upload目录权限用只读账号访问确认不可执行PHP容易被上传WebShellinstall目录状态确认已删除或改名后台配置可能被重置统计接口真实IP透传看download_log里的IP分布下载统计全部归到CDN节点IP升级接口version_compare客户端带1.9请求确认能匹配1.10版本比较翻车老用户永远提示最新签名校验这块多说一句。安卓侧上传APK后我建议后台自动记录签名信息用apksigner verify --print-certs的SHA-256值存库下次升级包上传时对比签名算法和证书指纹一致才允许覆盖。这套源码如果不带这个功能可以在后台应用详情页手动做一次校验记录升级时肉眼对比一下。预算里如果只有一台最低配的2C2G服务器扛得住日常分发但要注意upload目录的磁盘占用。IPA动辄两三百兆三个平台同时维护版本半年就能吃掉几十G。我的习惯是后台按版本保留最近三个更早的安装包定时任务清理。三个平台的预演动作各不一样安卓用一台Android 13的真机装一次确认签名和未知来源提示流程没问题苹果用一台iPhone装描述文件再走itms-services确认UDID回调、plist下载、安装三步全绿Windows找一台装过老版本的机器调一次check_update接口确认能拉到新版本且强更弹窗生效。这三步跑完我才会把后台账号交给运营。说个教训收尾。有一次客户催上线我跳过预演直接交付结果第二天苹果用户集体反馈装不上查了一下午才发现是IPA换过签名manifest里还是老Bundle ID的plist——那一次让我知道了分发系统这类东西看着简单出问题的时间成本全在后面。从那以后我每次交付都强制自己走一遍这份清单三个平台全绿再交钥匙。希望帮到你。本文还有配套的精品资源点击获取