必须制作自定义调试基座才能真实验证manifest配置功能，因标准基座共用dcloud预编译环境、忽略项目配置，而云打包生成独立签名apk并注入实际参数，二者运行环境完全不同。
开发阶段遇到真机运行和云打包结果不一致的问题，比如微信分享显示“HBuilder”而非你的应用名、推送功能失效、某些原生插件无法调用，根本原因在于二者加载的运行基座和资源路径完全不同。
真机运行用的是标准调试基座
点击“运行到手机或模拟器”时，HBuilderX默认安装并启动的是DCloud预编译的【HBuilder标准运行基座】，它是一个固定签名、固定第三方SDK配置（如微信AppID、极光推送Key）的通用容器。所有uni-app项目都共用这个基座，manifest.json里的配置几乎全部被忽略。
你改了微信登录的appid，在manifest里填得再准确，真机运行时照样走DCloud的测试appid——这就是为什么分享来源永远显示“HBuilder”。
这一步操作起来很简单，直接连接手机→点运行→自动安装基座→刷新页面即可看到效果，适合纯前端逻辑快速验证。
云打包生成的是独立签名APK
云打包会把你的完整项目代码（含manifest.json、资源文件、插件配置）上传至DCloud服务器，用官方统一环境编译成一个真正独立的APK文件。这个APK拥有你自己的包名、签名证书、第三方SDK配置，能真实反映上线后的行为。
HBuilderX 是由 DCloud 推出的一款轻量级前端开发工具，在 Linux 系统上主要用于 Web 开发与跨平台应用开发，尤其适合 Vue 和 uni-app 相关项目。
云打包过程中，DCloud会根据你manifest.json中填写的微信appid、Android key hash、推送通道等参数，动态注入到原生层，最终生成的APK可以上架应用商店。
注意：云打包生成的APK和真机运行的基座不是同一套代码路径，所以真机运行没问题 ≠ 云打包后没问题。
开发阶段怎么选：按阶段分三步走
第一步：日常UI/JS逻辑调试 → 用真机运行
第二步：涉及manifest配置的功能验证（如分享、推送、定位、摄像头） → 制作并运行【自定义调试基座】
第三步：封版前回归测试与发版准备 → 必须走云打包生成正式APK
制作自定义调试基座的操作路径：运行 → 运行到手机或模拟器 → 制作自定义基座 → 等待打包完成 → 手机安装该apk → 再次运行项目到该设备。这个基座使用你自己的证书和manifest配置，能真实模拟云打包后的表现，但仅限测试，不可商用。
如果你跳过第二步，直接用标准基座测微信登录，等到云打包后才发现签名不匹配导致授权失败，就得回退重配，浪费至少半天时间。
