uni.setscreenbrightness 和 uni.getscreenbrightness 可用但受限：微信小程序 ios 端 get 静默失败、set 可能被拦截；鸿蒙不支持；安卓 app 需 manifest 声明 write_settings 权限并动态申请；两者均为异步，亮度范围 0~1，需用 promise/await；安全还原须在全屏退出回调中 get+set，而非 onhide；setkeepscreenon 仅防息屏，不控亮度。
uni.setScreenBrightness 和 uni.getScreenBrightness 能不能直接用
能，但必须注意平台限制和异步特性——这两个 API 在微信小程序（安卓）、App（Android/iOS）、H5 均支持，但在微信小程序 iOS 端 uni.getScreenBrightness 会静默失败（不报错也不返回值），uni.setScreenBrightness 则可能被系统拦截；鸿蒙暂未开放系统级亮度控制权限，调用无效。
- 安卓 App 必须在
manifest.json中声明"android.permission.WRITE_SETTINGS"权限（非WAKE_LOCK），否则设置亮度无反应且无提示 -
uni.getScreenBrightness是纯异步接口，不能直接写let b = uni.getScreenBrightness(...)，必须用Promise或async/await封装 - 亮度值范围固定为
0~1，传1.2或-0.1会被截断，但不会报错，容易误以为“设成功了”
怎么安全地“先记亮度、再调高、退出时还原”
这是扫码、投屏、视频全屏等场景的刚需逻辑，核心是避免用户退出后屏幕仍过亮或过暗。关键不在“设”，而在“记”和“时机”。
- 别用
uni.setStorageSync存原始res.value—— 某些低端安卓机返回值可能是undefined或NaN，应 fallback 到0.5并显式判断：const saved = Number(res.value) || 0.5 - 还原动作不能放在
onHide，而要放在全屏退出回调或video的@fullscreenchange事件里（微信小程序中onHide触发太晚，系统已锁屏） - 如果用户手动滑动系统亮度条修改了值，你的
setScreenBrightness不会覆盖该操作，但下次调用getScreenBrightness会读到新值——所以“还原”本质是读取并重设，不是回滚
为什么 setKeepScreenOn 不能替代 setScreenBrightness
uni.setKeepScreenOn 控制的是“是否息屏”，和“亮度高低”完全无关。它只是阻止系统自动锁屏，屏幕依然可以是 0.1 的暗度，甚至被用户手动调成 0。
- 两者权限不同：
setKeepScreenOn只需WAKE_LOCK，setScreenBrightness在 Android 需WRITE_SETTINGS（运行时动态申请，iOS/HarmonyOS 不支持） - 常见错误：把
keepScreenOn: true当作“让屏幕变亮”，结果用户看到的是黑乎乎的常亮屏 - 组合使用才合理：比如播放页同时调用
uni.setKeepScreenOn({keepScreenOn: true})和uni.setScreenBrightness({value: 0.9})
安卓上 video 全屏后亮度异常，退出就卡死最低亮度
这是安卓微信小程序特有 bug：全屏 video 手势调低亮度 → 退出全屏 → 整个小程序所有页面亮度锁定在最低，且系统亮度条灰掉。根本原因是微信未重置系统亮度状态。
- 唯一有效解法：监听
video的@fullscreenchange="onFullscreenChange"，当detail.fullscreen === false时，立刻执行一次uni.getScreenBrightness+uni.setScreenBrightness组合（哪怕只是设回当前值） - 不要依赖
onUnload或onHide，它们在微信里触发不稳定，尤其从全屏退出时经常不执行 - 实测发现，即使只调一次
setScreenBrightness({value: 0.5})也能“唤醒”系统亮度控制，无需先 get —— 但为了兼容性，还是建议先 get 再 set
WRITE_SETTINGS 权限没动态申请——打包时加了权限，但没在 JS 里调 uni.authorize({scope: 'scope.writeSettings'})，结果 API 静默失效，连 console 都不报错。
