原理拆开看

微信小程序同时打开的页面栈通常最多 10 层，超过后不能继续通过 navigateTo 入栈；返回用 navigateBack，切换 tab 用 switchTab。这个值属于平台限制，面试时还应补一句：开发要以当前官方文档和实际基础库为准，页面层级过深本身也说明导航设计需要收敛。 小程序页面栈可以理解为一段受平台管理的导航历史：navigateTo 新增普通页，navigateBack 回退，redirectTo 替换当前页，reLaunch 重建整条栈，switchTab 切换到 tabBar 页面。具体层数是平台能力，不应把“能开多少层”当作导航设计目标。

最小实现

function openDetail(id) {
  const pages = getCurrentPages()
  if (pages.length >= 9) {
    wx.redirectTo({ url: `/pages/detail/index?id=${id}` })
    return
  }
  wx.navigateTo({ url: `/pages/detail/index?id=${id}` })
}

// tabBar 页面必须使用 switchTab
function goHome() {
  wx.switchTab({ url: '/pages/home/index' })
}

普通情况下用 navigateTo 保留返回路径；当页面栈已经很深时，示例改用 redirectTo 替换当前页，避免继续入栈。tabBar 页面不能用普通入栈 API，必须 switchTab。生产还应根据流程语义决定是否替换，不能只按数字硬切。

边界与排查

开发时先区分普通页和 tabBar 页，再根据用户是否需要返回选择入栈、替换或重建。可以用 getCurrentPages 查看当前栈深度，在接近上限前收敛跳转；订单、支付等流程还要避免重复入栈并处理从分享卡片直接进入中间页的情况。 基础库版本、tabBar 限制、分享冷启动和业务流程过深，都会影响导航行为。

原理拆开看

父传子用 props，子通知父由父组件下发回调；共享状态要提升到最近公共父级。层级很深再考虑 Context，跨页面且更新复杂才引入外部状态库，避免所有状态一上来就全局化。 React 题要先分清 render 阶段和 commit 阶段：前者计算下一棵界面树，可以被打断或重做；后者才真正修改宿主环境并执行布局相关副作用。组件的输入是 props、state、context 与外部订阅，优化的前提是先确认哪一个输入真的导致了重复工作。

最小实现

function Parent() {
  const [count, setCount] = React.useState(0)
  return <Counter value={count} onChange={setCount} />
}

function Counter({ value, onChange }) {
  return <button onClick={() => onChange(value + 1)}>{value}</button>
}

状态由真正拥有它的父组件保存，通过 props 向下传；子组件不直接改父状态，而是调用回调表达“希望发生什么”。兄弟组件共享时把状态提升到最近公共父级，跨很多层再考虑 Context 或外部 store。

边界与排查

排查时先用 React DevTools Profiler 录制一次真实交互，再看是哪一层组件重复 render、提交耗时落在哪里。不要一上来堆 memo；引用每次都重建、状态放得太高或 effect 依赖不完整，都会让表面优化失效。涉及生命周期和事件时还要主动说明 React 16、17、18+ 的版本边界。 版本、并发渲染、组件卸载和 Strict Mode 重复检查，是这类题最常被追问的边界。