开发记录：Nuxt自动导入与隐式依赖边界重构

这篇开发记录用于复盘 M5-12 的背景、目标、执行过程和最终结果。

为什么在 M5-12 补 Nuxt自动导入与隐式依赖

前面的案例已经覆盖了页面、基础组件、SSR、Nuxt 页面数据、状态管理、复杂交互、认证权限、路由壳层、错误隔离、异步加载、Nuxt 运行时边界、Nuxt 响应策略和 Nuxt 执行时机，但在真实 Nuxt 项目里，还有一条会不断穿透这些内容的横向主线：项目省掉了很多 import 之后，依赖关系到底还能不能一眼看清。

只要这条链路没有收口，前面任何一类场景都会逐渐出现问题：

• 页面和组件虽然更短了，但依赖来源越来越隐式
• composables/ 和 utils/ 越来越像公共大仓库
• imports.dirs 一路膨胀，目录边界越来越弱
• server-only、client-only 和双端共享能力混在同一套入口里

所以 M5-12 选择 Nuxt 自动导入与隐式依赖，是为了把“公共入口、局部实现、目录治理、环境前提、调用可读性”这一条非常常见的横向架构线补齐。

这轮做了什么

这轮主要完成了这些事情：

• 新增 Nuxt 自动导入与隐式依赖案例文档
• 新增 M5-12 任务拆解文档
• 新增 M5-12 详细设计文档
• 更新里程碑、入口、导航与统一框架
• 将 Nuxt 依赖边界型案例正式纳入当前方法库

这轮最重要的决策

决策一：先讲依赖分层，再讲自动导入配置

这轮没有把重点放在“配置怎么写”，而是放在：

• 哪些能力属于默认框架自动导入
• 哪些能力应该成为应用公共入口
• 哪些能力必须留在 feature 内部显式导入
• 为什么 server-only 和 client-only 能力不能被同一种隐式入口吞掉

决策二：选自动导入与现有 Nuxt 案例共同作为素材来源

这组素材非常适合作为案例来源，因为它刚好覆盖了：

• Nuxt 默认自动导入能力
• 页面数据和运行时能力的稳定入口
• 生命周期与环境边界
• 自动导入便利性和依赖清晰度之间的张力

它很适合作为“从少写 import，走向依赖治理”的过渡案例。

决策三：把页面消费轻量和依赖显式可读放到同一套语义里

这轮没有把“页面要轻”理解成“调用点越短越好”，而是把重点放在：

• 页面应该只消费少量稳定入口
• feature 内部实现仍然应该保留显式依赖关系
• 自动导入应该服务于边界稳定，而不是继续掩盖结构问题

这样新案例就能直接挂到当前已经形成的统一框架里。

本轮自测怎么做

这轮仍然只修改文档，因此自测继续聚焦文档完整性：

• 检查新增 Markdown 文件是否生成成功
• 检查本地链接是否全部可解析
• 检查入口页、导航图和总框架是否已经接入新案例
• 检查 M5-12 的任务拆解、详细设计和开发记录是否齐全

本轮结果

M5-12 完成后，当前方法库已经不只覆盖状态、渲染、交互、认证、路由、容错、异步加载、运行时边界、响应策略和执行时机问题，也开始覆盖 Nuxt 依赖组织本身的一条基础主线：自动导入边界、公共入口设计、隐式依赖控制与环境分层。

这意味着后续如果继续扩展：

• 大型 Nuxt 项目的 composable 目录治理
• 自动导入与模块公共 API 设计
• server-only / client-only 能力分层
• 页面顶层依赖可读性治理
• Nuxt 项目级依赖图收口

都已经有了稳定挂载点。