为什么传统鉴权方式总出问题？先搞懂拦截器的核心优势
你可能会说，“判断登录状态还不简单？每个页面onPageShow的时候检查一下不就行了？” 我一开始也是这么想的。但做了3个页面后就发现不对劲：首页、消息页、个人中心，每个页面都要写“if (!isLogin) { navigateToLogin() }”，代码重复得像复制粘贴，后来新增了“收藏页”，忘了加这段判断，结果未登录用户直接能进去，数据接口报错，被测试骂惨了。这就是传统“页面内硬编码”的第一个坑：逻辑分散，漏写就翻车。
后来我们改用全局变量存登录状态，在AppStorage里放个isLogin，每个页面从AppStorage取。但新问题又来了：用户在A页面触发登录，登录成功后AppStorage的isLogin变了，可B页面已经onPageShow过了，不会重新检查，导致“明明登录了，B页面还显示未登录”。这就是第二个坑：状态同步滞后，拦截不及时。
直到看到鸿蒙开发者文档里提到“Navigation组件支持拦截器机制，可在页面跳转前对目标路由进行预处理”（鸿蒙官方文档链接，nofollow），我才明白拦截器的优势——它就像小区门口的保安，所有页面跳转都要先经过它检查，既不用在每个“住户”（页面）门口贴告示，又能实时拦住“未授权人员”。而且它还能记住“访客本来要去几楼”，等登记完（登录）直接送上去，这就是路径保存和恢复能力，传统方式得自己写一堆栈管理代码才能实现。
手把手实现拦截器鉴权：从配置到回跳的5个关键步骤
别担心代码复杂，我把核心步骤拆成了“配置-监听-拦截-登录-回跳”5步，每步都有可直接抄的示例。
步骤1：初始化拦截器，给Navigation装“保安亭”
首先在main_pages.json里定义好所有页面路由，比如首页是“pages/Index”，登录页是“pages/Login”，个人中心是“pages/UserCenter”。然后在AbilityStage的onCreate里，给Navigation注册拦截器：
// 伪代码示例，实际开发需用ArkTS
navigationInterceptor = new NavigationInterceptor()
navigationInterceptor.setInterceptor((targetUri: string) => {
// 这里写拦截逻辑，true=拦截，false=放行
return needIntercept(targetUri)
})
Navigation.setInterceptor(navigationInterceptor)
我当时犯过一个错：拦截器注册晚了，首页已经加载完才初始化，导致首页跳转的第一个页面没被拦截。后来把注册放在AbilityStage的onCreate，确保应用启动时就准备好，才解决问题。
步骤2：设计登录状态监听，让“保安”知道谁能进
拦截器得知道“谁是已登录用户”，这就需要实时监听登录状态。我推荐用AppStorage+Preferences组合：AppStorage存内存中的实时状态，Preferences存本地持久化状态（避免重启应用后登录状态丢失）。代码里这样写：
// 初始化登录状态
AppStorage.SetOrCreate('isLogin', false)
let preferences = await preferences.getPreferences(getContext(), 'user_prefs')
let savedLoginState = preferences.get('isLogin', false)
AppStorage.SetOrCreate('isLogin', savedLoginState)
// 登录成功后更新状态
function loginSuccess() {
AppStorage.Set('isLogin', true)
preferences.put('isLogin', true)
}
这样拦截器随时能从AppStorage取到最新的isLogin，不用自己轮询检查。
步骤3：写拦截规则，明确“哪些页面要拦，哪些不用拦”
不是所有页面都需要拦截，比如登录页、注册页、帮助页，这些是“公共区域”，未登录用户也能进。我当时列了个白名单，用表格管理（如下），拦截器会先检查目标页面是否在白名单里，不在的话再判断登录状态：
| 页面路由 | 页面名称 | 是否需要登录 | 拦截优先级 |
|---|---|---|---|
| pages/Index | 首页 | 否 | 不拦截 |
| pages/Login | 登录页 | 否 | 不拦截 |
| pages/UserCenter | 个人中心 | 是 | 高 |
| pages/MessageDetail | 消息详情 | 是 | 高 |
表：常见页面的登录权限与拦截优先级配置示例
步骤4：拦截后怎么跳登录页？关键是“记住要去哪儿”
当拦截器判断“需要拦截”（目标页需登录且当前未登录），就该跳转到登录页了。但直接navigateTo(‘pages/Login’)不行，因为登录成功后，用户想回到刚才的目标页。所以要先把目标页的Uri存起来，比如用AppStorage存个“targetUri”：
// 拦截逻辑里添加路径保存
if (needIntercept(targetUri)) {
AppStorage.Set('targetUri', targetUri) // 存目标路径
router.pushUrl({ url: 'pages/Login' }) // 跳登录页
return true // 拦截跳转
}
我之前试过用全局变量存路径，结果用户在登录页没登录，又点了其他需登录的页面，新路径把旧路径覆盖了，登录后跳错页面。后来改用AppStorage+Preferences双重存储，即使应用被杀后台，也能从Preferences恢复路径，稳妥多了。
步骤5：登录成功后回跳，别让用户“重新找路”
登录页登录成功后，关键是恢复之前保存的路径。如果有targetUri，就跳过去；没有就默认跳首页：
// 登录页登录成功回调
function onLoginSuccess() {
loginSuccess() // 更新登录状态
let targetUri = AppStorage.Get('targetUri') as string
if (targetUri && targetUri !== '') {
router.pushUrl({ url: targetUri }) // 跳回目标页
AppStorage.Set('targetUri', '') // 清空路径，避免重复跳转
} else {
router.pushUrl({ url: 'pages/Index' }) // 默认跳首页
}
}
这里要注意：如果用户在登录页点“取消”，需要清除targetUri，否则下次进应用可能还会被拦截到登录页。可以在登录页的onPageHide里加一句“AppStorage.Set(‘targetUri’, ”)”，确保取消登录后不保留旧路径。
最后给你留个测试清单，照着跑一遍，基本不会出问题：未登录点个人中心→拦截到登录页；登录成功→回个人中心；未登录点消息详情→拦截登录→取消登录→回到原页面；登录超时后点需权限页面→重新拦截。如果这些场景都通过，说明你的拦截器已经“上岗”了。要是遇到奇怪的bug，比如“回跳后页面数据没加载”，记得检查目标页有没有在onPageShow里重新请求数据——我当时就忘了这步，页面是跳回去了，但数据还是旧的，又折腾了半小时才发现。
你按这些步骤做下来，应用的登录体验会顺畅很多。要是试了有效果，或者遇到新问题，欢迎回来告诉我，咱们一起优化！
你可能会担心，在每个页面跳转前加个拦截器，会不会让应用变慢？我之前专门在鸿蒙Next开发者预览版上测过，其实完全不用慌。Navigation拦截器就像小区门口的保安，平时不会一直盯着你，只有你要进单元门（跳转页面）的时候才会上前看一眼通行证（检查登录状态）。单次拦截逻辑从判断状态到决定是否放行，整个过程通常都在10ms以内，比你眨下眼还快，根本感觉不到延迟。
反倒是传统的页面内硬编码，我之前帮人改代码时见过一个极端情况：一个应用有10个需要登录才能进的页面，每个页面的onPageShow里都写了登录检查。用户从首页跳到消息页，再到收藏页、个人中心……每跳一次，就执行一次“查登录状态”的代码，等于10个页面重复做了10遍同样的事。更麻烦的是，有些页面还会在onPageAppear里再查一次，等于双重检查，结果用户连续跳转时，手机后台日志里全是重复的判断逻辑，反而拖慢整个应用的响应速度。这么一比，拦截器这种“集中检查一次”的方式，明显高效多了。
拦截器鉴权方案是否适用于所有鸿蒙应用形态？
拦截器鉴权方案主要适用于使用Navigation组件进行页面路由管理的鸿蒙应用，包括手机、平板、智慧屏等多端应用。但需注意：若应用采用纯StageExtensionAbility（如服务卡片）或无页面跳转场景（如后台服务），则无需集成；对于分布式应用，跨设备页面跳转时需额外处理设备间的登录状态同步（可结合鸿蒙分布式数据管理能力实现）。
拦截器鉴权会影响应用性能吗？和页面内硬编码相比哪个更高效？
拦截器鉴权对性能影响极小。Navigation拦截器仅在页面跳转时触发预处理，单次拦截逻辑耗时通常在10ms以内（实测数据基于鸿蒙Next开发者预览版），远低于页面渲染耗时。相比之下，传统页面内硬编码需在每个页面的onPageShow/onPageAppear生命周期重复执行判断逻辑，若应用有10个需鉴权页面，用户连续跳转时会触发10次重复检查，反而更耗性能。
未登录用户的目标路径保存在哪里？会有安全风险吗？
目标路径 存储在应用内存中（如AppStorage或临时变量），而非持久化存储（如Preferences）。例如文章中提到的“targetUri”仅在应用运行时临时保存，用户退出应用后自动清除，避免敏感路径信息泄露。若需支持“杀后台后恢复路径”，可加密存储路径（如使用鸿蒙安全框架的加密API对路径字符串加密后存入Preferences），登录成功后解密使用，降低安全风险。
多个需拦截的页面同时触发跳转，拦截器如何处理优先级？
拦截器支持通过“路由优先级”控制处理顺序。可在拦截规则中为不同页面设置优先级（如消息详情页优先级>个人中心页），当多个拦截请求同时触发时，按优先级从高到低处理。例如用户快速点击“消息详情”和“个人中心”，拦截器会优先保存“消息详情”的路径并跳转登录页，登录后优先回跳至消息详情页。实现时可在拦截规则中添加“priority”字段，数值越大优先级越高。
登录成功回跳后，目标页面的数据需要重新请求吗？
需要。因为目标页面在被拦截前可能已执行过初始化逻辑（如onPageInit），但未获取到用户数据（因未登录）。 在目标页面的onPageShow生命周期中添加数据刷新逻辑，例如：登录成功回跳后，目标页面检测到登录状态变化，自动调用数据请求接口（可通过监听AppStorage中的isLogin状态实现）。示例代码可参考：“if (AppStorage.Get(‘isLogin’)) { fetchUserData() }”，确保页面展示最新数据。
