原生导航栏按钮无法动态toggle，APP端需用setTitleNView替换整个buttons数组，H5和小程序端只能预设多套配置或模拟禁用。
原生导航栏按钮状态不能直接 toggle，得靠 uni.setNavigationBarColor + titleNView 组合控制
uni-app 的原生导航栏按钮（navigationBarButtons）一旦在 pages.json 里声明，就无法通过 JS 动态“显示/隐藏”或“启用/禁用”单个按钮——它没有类似 disabled 的运行时属性。所谓“动态改变状态”，实际是指：在不同页面生命周期中，用不同配置覆盖当前导航栏的整个 titleNView 结构。
关键限制是：uni.setNavigationBarColor 只能改背景和文字色，不触碰按钮；真正能增删按钮的，只有 app-plus 平台下的 titleNView 配置，且必须在页面 onReady 或之后调用 setStyle。
- 按钮定义必须写死在
pages.json的navigationBarButtons里，H5 和小程序端不支持运行时注入新按钮 - APP 端可通过
webView.setTitleNView替换整套titleNView配置（含buttons数组），实现“看起来是动态切换” - 小程序端按钮状态只能靠「提前配好两套按钮数组 + 切换页面时用
uni.navigateTo带参数」间接模拟，无法实时刷新 - 别在
mounted里就调，务必等onReady后再获取 webview 实例，否则$getAppWebview()返回undefined
app-plus 下用 setTitleNView 替换按钮数组
这是唯一能真正在 APP 端运行时“改变按钮”的方式。本质是把原生导航栏当做一个可重绘的视图，用新 JSON 配置完全覆盖旧的。
示例：进入详情页后隐藏“分享”按钮，只留“返回”
onReady() {
const pages = getCurrentPages();
const page = pages[pages.length - 1];
const webView = page.$getAppWebview();
if (webView) {
webView.setTitleNView({
buttons: [{
type: 'back',
style: { width: '44px', height: '44px' }
}]
});
}
}- 注意：传入的
buttons是完整数组，不是增量更新；没写的按钮会消失 -
type: 'back'是系统内置类型，不支持自定义图标路径；如需图标按钮，必须用fontSrc+text拼字体图标（如 iconfont） - 调用后不会触发页面重绘，但按钮区域会立即响应新配置 —— 这也是为什么必须在
onReady后操作
H5 和小程序端只能“预设多套” + 路由判断
H5 端按钮渲染在 DOM 中，可用原生 JS 操作 .uni-page-head-btn 元素的 style.display；小程序端则完全无运行时 API 控制按钮显隐，只能靠页面级配置隔离。
通用做法是：在 pages.json 里为不同角色/状态的页面，分别配置不同的 navigationBarButtons 数组，然后在页面 onLoad 中根据参数决定是否“假装按钮失效”：
- H5 端可这样临时隐藏第一个按钮：
document.querySelectorAll('.uni-page-head-btn')[0]?.style.display = 'none' - 小程序端建议用
if包裹按钮逻辑，在onNavigationBarButtonTap里判断当前权限再执行动作，视觉上“按钮还在，点不动” - 所有平台都应避免跨页面污染：用
page.route === 'pages/detail/index'明确限定作用域，防止上一页按钮也被误改
容易被忽略的兼容性断层
最常踩的坑不是代码写错，而是误以为三端行为一致。实际上：
- APP 端按钮支持
fontSize、color、width/height精细控制；H5 端只认内联样式，且 class 名可能随 uni-app 版本变化 - 小程序按钮点击事件回调里拿不到按钮 ID，只能靠
index匹配navigationBarButtons顺序 —— 所以动态删按钮会导致index错位 - 全局
navigationStyle: "custom"会彻底关掉原生导航栏，此时所有“原生按钮”都不存在，讨论动态状态毫无意义
真正需要动态按钮状态的场景，基本都该转向自定义导航栏组件 —— 原生方案的灵活性边界，比文档写的更窄。
