别一上来就设 navigationStyle: "custom"，否则小程序页面首行文字大概率被状态栏遮盖；需手动通过 statusBarHeight 获取高度并用 CSS 变量适配，鸿蒙平台不支持 titleNView 的按钮和搜索框。
直接结论：别一上来就设 navigationStyle: "custom"，否则小程序页面第一行文字大概率被状态栏盖住——这是最常踩的坑。
pages.json 里该配 titleNView 还是 navigationStyle？
取决于你要不要兼容微信小程序：
-
titleNView: false只影响 H5 和 App，小程序完全无视它，原生导航栏照常显示，不会白屏也不会遮挡内容 -
navigationStyle: "custom"是全平台强制开关，小程序也会移除原生导航栏，但不自动预留状态栏空间，结果就是页面<view>从 y=0 开始渲染，顶部被信号栏、时间压掉 - 二者不能共存于同一页面 style 中：
navigationStyle优先级更高，会覆盖titleNView的行为
小程序端用了 navigationStyle: "custom" 后内容被“砍头”，怎么修？
必须手动处理状态栏高度，H5 返回 0、小程序返回真实像素值（iOS 约 44px，Android 多为 20–25px）：
- 在页面
<script>中用uni.getSystemInfoSync().statusBarHeight拿值（注意：onLoad阶段即可调用） - 在
<template>顶部加一层空<view class="status-bar"></view>，CSS 设height: var(--status-bar-height) - 更稳妥的做法是在
<style>中注入 CSS 变量：::root { --status-bar-height: env(safe-area-inset-top, 20px); }，兼顾 iOS 安全区
自定义导航栏到底该手写 <view> 还是用 titleNView 配置？
看需求复杂度：
- 只改背景色、加返回按钮、设标题文字 → 直接配
app-plus.titleNView，H5 也认，性能稳、无兼容风险 - 要塞搜索框、用户头像、tab 切换、下拉菜单 → 必须手写
<view class="custom-nav-bar">，配合position: fixed+ 状态栏适配 - 用 uView 或 uni-ui 的
<uni-nav-bar>组件？本质仍是手写<view>，仅封装了基础样式和事件，没解决状态栏问题，该算高度还得自己算
真正容易被忽略的点是：鸿蒙平台不支持 titleNView 配置里的按钮和搜索框，哪怕你写对了字段，运行时也无效——这时只能退回到 navigationStyle: "custom" + 手写导航栏的老路，且得单独测鸿蒙的软键盘顶起逻辑。
