{
"dependencies-pod-sources": [
"https://github.com/CocoaPods/Specs.git"
],
"dependencies-pods": [{
"name": "AMapNavi",
"version": "10.1.302"
},
{
"name": "AMapSearch",
"version": "9.7.4"
}
],
"deploymentTarget": "13"
}
9***@qq.com
- 发布：2026-07-27 17:32
- 更新：2026-07-27 17:33
- 阅读：27
产品分类： uniapp/App
PC开发环境操作系统： Mac
PC开发环境操作系统版本号： macOS Tahoe 版本26.5.2
HBuilderX类型： 正式
HBuilderX版本号： 5.15
手机系统： iOS
手机系统版本号： iOS 26
手机厂商： 苹果
手机机型： iPhone 15 Pro max
页面类型： vue
vue版本： vue3
打包方式： 云端
项目创建方式： HBuilderX
示例代码：
操作步骤：
开发 iOS高德地图UTS插件，通过Cocopods导入，云打包出现图片资源重复，最近才出现，以前没问题
开发 iOS高德地图UTS插件，通过Cocopods导入，云打包出现图片资源重复，最近才出现，以前没问题
预期结果：
不能重复导入
不能重复导入
实际结果：
不能重复导入
不能重复导入
bug描述：
DCloud 云打包iOS包，集成了高德地图UTS插件，最近打包时发现包体积增加了30兆左右，以前都没问题
同一个 App 的两个不同版本，不是重复打包。
17MB 差距的三大原因
- 高德地图资源重复打包（~30MB，最主要原因）
v2.1.4 包的 unimoduleWtNativeMap.framework 内部多包含了：
AMapNavi.bundle（25MB）
AMap.bundle（5.1MB）
而这两个 bundle 同时也在 app 根目录存在，等于高德地图导航和地图资源被存了两份。小体积 包只在根目录有，framework 内没有，所以小了约 30MB。
代码UTS 插件 WtNativeMap 通过 CocoaPods 依赖高德 SDK，v2.1.4 云打包后 unimoduleWtNativeMap.framework 内部多出了 AMapNavi.bundle(25MB) 和 AMap.bundle(5MB)，与 app 根目录的 bundle 重复，导致 IPA 从 65MB 膨胀到 82MB。
Ask小助手 - Ask社区AI助手
欢迎到专业群（ uni-app x技术交流群 ） 咨询，群中有相关专业的管理员和群友。
针对你提交的“DCloud 云打包 iOS 包，集成了高德地图 UTS 插件导致包体积异常增加”的 Bug 反馈，以下是官方视角的评审与分析意见：
1. Bug 反馈内容完整度评审
整体评价：
该 Bug 反馈的质量非常高，属于典型的“优秀提报”案例。你不仅描述了表象，还直接定位了问题根因，并给出了具体的包体积差异对比和资源文件路径，极大降低了官方排查和复现的成本。
分项检查：
- BUG 描述：非常详细且清晰。明确指出了体积增加 17MB（标题描述 20MB/30MB，正文细化了 17MB 差距），并精准定位到
unimoduleWtNativeMap.framework内部多包含了AMapNavi.bundle(25MB) 和AMap.bundle(5.1MB)，与 App 根目录存在重复打包。无需补充，官方人员完全可以看懂。 - 代码示例：提供了
package.json中的 CocoaPods 依赖配置，版本号明确（AMapNavi10.1.302,AMapSearch9.7.4）。虽然这不是完整工程，但对于排查云打包资源拷贝逻辑已经足够，无需要求你提供完整可运行项目。 - 复现步骤：清晰明了。结合你提供的依赖配置和版本号，官方可以通过在 iOS UTS 插件中引入相同版本的高德 SDK 进行云打包来验证资源是否重复。
- 预期结果与实际结果：预期“不能重复导入”合理且符合工程逻辑；实际结果描述一致。不存在误报情况。
- 分类信息：完整。涵盖了 PC 环境（macOS Tahoe 26.5.2）、HBuilderX 版本（正式版 5.15）、手机平台及机型（iOS 26, iPhone 15 Pro max）、Vue 版本（Vue3）。
2. Bug 是否成立及根因分析
Bug 状态：成立。
从 uni-app x 的 iOS 插件工程体系来看，这个现象的根因是明确的。在 iOS 平台，UTS 插件通过 CocoaPods 引入高德 SDK 时，SDK 附带的 .bundle 资源文件（如 AMapNavi.bundle、AMap.bundle）会被 CocoaPods 下载并默认存放在 Pods 工程的特定目录下。
在云打包过程中，编译引擎会将 UTS 插件编译为独立的 Framework（即你观察到的 unimoduleWtNativeMap.framework）。如果打包脚本在处理资源 Copy Phase 时，将属于 Pod 依赖的资源错误地打入了插件 Framework 内部，同时主工程的资源拷贝流程又将这些 bundle 放到了 App 根目录，就会导致高德地图的图片等资源被存两份，从而引发 IPA 体积膨胀近 30MB。
根据官方 iOS 云端打包环境说明（参考 HBuilderX5.05及以上版本云端打包环境），目前云打包机已升级至 XCode 26.3。这种体积异常极有可能是近期打包环境升级（如 XCode 升级或 CocoaPods 版本变更）导致 Pod 资源拷贝策略发生改变而引发的回归问题。
3. 下一步处理建议与替代方案
-
提交 Issue 跟进：
由于你已经定位到非常具体的文件路径和 bundle 名称，建议直接在 DCloud 官方 Issue 系统提交此问题：https://issues.dcloud.net.cn/。在 Issue 中直接附上你本次的描述和对比数据，该问题属于打包引擎层面的资源拷贝缺陷，官方可以快速定位并修复云打包脚本。 -
临时规避方案：
在官方修复该云打包资源拷贝逻辑之前，如果这 30MB 的增量严重影响了你的发布或触发了云打包体积计费（参考 App 大小超限计费规则），你可以尝试以下方式规避：- 尝试在 UTS 插件的 iOS 原生配置中，不通过 CocoaPods 引入高德 SDK 的完整包，而是改为下载高德 SDK 的
.framework或.xcframework形式，手动放入插件的app-ios/Frameworks目录中，并手动管理其 bundle 资源，只放置在插件或主工程目录一次。 - 如果条件允许，可暂时回退 HBuilderX 版本（如 4.x 版本）测试云打包，以验证是否确实是最新版打包环境升级导致的回归。
- 尝试在 UTS 插件的 iOS 原生配置中，不通过 CocoaPods 引入高德 SDK 的完整包，而是改为下载高德 SDK 的
内容为 AI 生成，仅供参考
