标准答案
- 迁移前要明确目标，是降低状态复杂度、升级渲染架构、改善性能，还是支持多团队交付。
- 不要一次性全量重写，应从低风险或高收益模块试点，建立可复制模式。
- 新旧状态库并存时可以用适配层隔离调用方，避免页面直接依赖两套实现细节。
- 迁移期间要保持路由、埋点、权限、错误处理和测试覆盖稳定。
- 每个阶段都要有回滚方案和验收指标，例如错误率、性能、开发效率或包体变化。
题目解析
这道题考的是工程治理。迁移不是技术选型结束后直接开改，而是持续控制风险。
状态库迁移尤其要注意数据来源、更新顺序和副作用位置，否则容易出现新旧状态不一致。
好的迁移计划会把业务交付和技术演进并行推进，而不是长期冻结需求。
代码示例
下面用适配 Hook 隔离调用方，让页面不用关心底层状态库是否已迁移。
TSX
function useCurrentUserModel() {
const currentUser = useNewUserStore(state => state.currentUser)
const updateUser = useNewUserStore(state => state.updateUser)
return {
currentUser,
updateUser
}
}
function ProfileHeader() {
const { currentUser } = useCurrentUserModel()
return <span>{currentUser.name}</span>
}常见误区
- 把迁移做成全量重写，业务验证和回滚成本都很高。
- 新旧状态库同时被页面直接使用，状态来源混乱。
- 只迁移代码，不补测试、监控和错误回滚方案。