splashscreen.duration仅对Android生效，需置于splashscreen下、单位毫秒、配合autoclose:true和waiting:true；iOS由Storyboard控制且不可配；鸿蒙复用Android配置但受系统限制。
manifest.json 里 duration 字段必须写在 splashscreen 下，且只对 Android 生效
uni-app 的启动图持续时间由 splashscreen.duration 控制，但它**仅影响 Android 平台**；iOS 启动图由 Storyboard 控制，系统接管时长，无法通过配置修改。常见错误是把 duration 写在根节点或 app-plus 外层，或者误以为它对 iOS 也起作用。
-
duration单位是毫秒，比如3000表示 3 秒，最小建议不小于1500，否则部分低端 Android 设备可能来不及加载首页就关闭了启动页 - 必须和
autoclose: true、waiting: true同时存在，否则duration可能被忽略 - 若首页 JS 加载慢，仅靠
duration不够——需配合alwaysShowBeforeRender: true（Android 专属），防止白屏闪一下就跳走
iOS 启动图时长不能配，但可间接延长“视觉停留感”
iOS 真机上，LaunchScreen.storyboard 显示时长由系统决定（通常 0.5–1.5 秒），你改任何 manifest 配置或 JS 逻辑都无效。想让用户感觉“启动图久一点”，只能从视觉层面入手：
- Storyboard 中背景图用
Aspect Fill拉伸模式，确保全屏无留白；文字/Logo 必须提前画进 PNG 里，Storyboard 不支持动态文本 - 启动图背景色要和
pages.json里globalStyle.background一致，否则关闭瞬间会“跳色”，造成割裂感 - 不要依赖
splashscreen.ios.image：该字段在真机上被静默忽略，Xcode 打包时也不会读取，写了也没用
别用 JS 延迟关闭——云打包后根本不起作用
有人试图在 App.vue 的 onLaunch 里调用 plus.navigator.closeSplashscreen() 或 setTimeout，这在 HBuilderX 本地调试可能“看起来有效”，但云打包后会被原生层拦截或忽略。原因很直接：iOS 启动图关闭时机由系统控制；Android 启动图一旦 autoclose: true，JS 层调用关闭接口已失效。
- 所有 JS 层的启动图控制逻辑（包括插件如
uni-app-plus-splashscreen）在云打包后的正式 App 中均不生效 - 如果你看到 JS 控制成功，大概率是没走云打包，还在用离线调试或模拟器运行
- 真正可控的只有 manifest 静态配置 + 原生资源文件 + 云打包三者闭环
鸿蒙平台完全复用 Android 配置，但 duration 仍受限于系统策略
鸿蒙打包时，uni-app 会自动读取 app-plus.splashscreen.android 下的配置，包括 duration。但注意：鸿蒙系统本身对启动图展示时长也有兜底限制（通常 1–2 秒），即使你设了 5000，实际也可能被截断。
- 鸿蒙图标只读
xxxhdpi，但启动图时长不额外提供字段，别去建harmonyos节点 - 如果发现鸿蒙启动图一闪就过，优先检查是否漏了
waiting: true，而不是盲目加大duration - 鸿蒙调试必须走「发行 → 原生 App-云打包 → 勾选 HarmonyOS」，本地运行或 HBuilderX 真机调试不加载 splashscreen 配置
最常被忽略的一点：iOS 启动图不是“图片+时间”模型，而是“系统接管的过渡界面”。你花时间调 duration，不如花时间校准 LaunchScreen.storyboard 里的约束和图片命名——少一个 @2x 后缀，整个启动图就 fallback 成白屏。
