结论：微信小程序页面栈上限为10层，navigateTo每调用一次栈深+1，超限即报错“page limit exceeded: 10”；navigateBack仅出栈不销毁页面，栈深持续累积；应按业务意图选用redirectTo、navigateBack或reLaunch，并严格校验分包路径格式与注册配置。
直接说结论：不是路径“过深”，是页面栈“超限”——微信小程序强制限制页面栈最多 10 层，navigateTo 每调用一次就 +1，超过就报 navigateTo: fail: page limit exceeded: 10，跳转静默失败。
为什么 navigateTo 会累积页面栈？
很多人误以为“返回”就能清栈，其实 navigateBack 只是出栈，并不销毁已加载的页面实例；而每次 navigateTo 都会把新页压入栈顶。比如列表页反复点“新增”→“返回”，实际栈是：[list] → [list, add] → [list] → [list, add] → ……只要没主动清理或替换，历史页一直留在内存里。
- 小程序运行时只认栈深度，不管页面是否“已返回”
-
getCurrentPages().length可实时查看当前栈深，调试时加一行就能验证 - H5 和 App 端无此限制，问题只出现在微信/支付宝等小程序平台
怎么选对跳转 API？看业务要不要“返回”
别硬扛着全用 navigateTo，根据用户操作意图换 API 才是正解：
- 需要返回上一页（如列表→详情→再回列表）→ 保留
navigateTo - 跳转后无需返回（如详情→支付成功页、登录页→首页）→ 改用
redirectTo，栈深不变 - 必须回到某一层且带参（如地址选择页→订单页）→ 用
navigateBack+getCurrentPages()获取上一页实例传参，而不是再navigateTo回去 - 要彻底重置（如退出登录后跳首页）→ 用
reLaunch，栈只剩目标页
分包页面跳转失败？90% 是路径写错了
分包路径不是文件路径，而是 pages.json 里注册的逻辑路由。写错就静默失败，控制台甚至不报错。
- 必须以
/开头，例如/suba/pages/list/list，不能写成suba/pages/list/list或./suba/... -
subpackages节点里声明的root值，必须和路径第一段完全一致（大小写、斜杠方向都敏感） - 检查
pages.json是否把目标页写进了对应分包的pages数组，而非主包的pages - 真机调试时打开“调试器 → Network”，看请求的分包 JS 是否 404，能快速定位注册问题
真正容易被忽略的是：页面栈超限往往不是单次跳转导致的，而是多个页面共用同一套跳转逻辑（比如所有“新增”按钮都用 navigateTo），问题在第 10 次之后才暴露。上线前务必用 getCurrentPages().length 在关键跳转前后打点，而不是等用户反馈“点不动了”才排查。
