用途
本技能面向 Drupal 功能开发前期的设计与思考阶段，目标是：在写代码前完成结构化探索，避免 Drupal 开发中最昂贵的错误，例如实体类型选错、测试类型选错、缺少访问控制或引入不必要的复杂度。
何时使用
- 开始一个新功能或新模块
- 为现有代码添加较重要功能
- 不确定该用内容实体、配置实体，还是都不需要
- 在 hook、事件或插件之间做选择
- 多模块改动，影响范围不清楚
四步流程（约 5 分钟）
第一步：明确意图
先问自己（或用户）几个问题：
- 这解决什么问题（而不是要写什么代码）
- 谁使用它（管理员、已认证用户、匿名用户、API 消费者、cron）
- 已经存在什么？运行
discover deps:MODULE或检查结构索引 - 能工作的最简单版本是什么
不要跳过这一步。最常见的失败模式是把错误的东西正确地建出来。
第二步：实体与数据设计
Drupal 早期最具影响的决策是数据如何存储：
- 数据带修订、访问控制、字段、视图 → 内容实体
- 站点配置（设置、映射）→ 配置实体
- 临时或计算型数据（缓存、队列、状态）→ 不用实体，使用 State API、Queue 或 cache
- 简单键值对 →
\Drupal::state()或 config
常见陷阱：在配置实体或 State API 就足够时创建内容实体。内容实体成本较高（数据库表、访问处理器、视图集成），只有在需要完整实体生命周期时才使用。
第三步：架构草图
为每个组件做决定：
- 业务逻辑：服务类，始终是服务，不放在控制器或 hook 中
- 数据访问：Entity API，绝不用原生 SQL
- 用户交互：Form API 加控制器；变更用表单，展示用控制器
- 后台工作：Queue 加 AdvancedQueue，不用 cron hook
- 外部调用：通过依赖注入使用 Guzzle，绝不用
file_get_contents - 事件：EventSubscriber，跨模块关注点优先用事件而非 hook
- 展示：Twig 加预处理，重逻辑放在预处理中而非 Twig
影响范围检查：多模块改动前，运行 discover deps:FEATURE 查看依赖关系。
第四步：决策记录
用 3-5 行记录决策，例如：
- 实体：配置实体（仅设置，无需修订）
- 服务：
my_module.processor（业务逻辑）、my_module.client（外部 API） - Hook：
hook_cron用于定时检查，使用#[Hook]属性风格 - 访问：自定义权限
administer my_module - 测试：服务用 Kernel 测试，管理员表单用 Functional 测试
该记录可作为编写计划或直接实现的输入。
反模式
- 先建后理解：用写代码来“探索”，而不是阅读现有代码
- 实体泛滥：为本应是配置或状态的数据创建实体
- 上帝服务：一个服务做所有事，应按职责拆分
- 过早抽象：为只有一个实现的东西创建接口、插件和工厂
- 忽视现有模块：自建前检查 contrib 是否已解决
输出
思考结束后应有：
- 清晰的问题陈述（1-2 句）
- 实体与数据设计决策及理由
- 服务架构草图（哪些服务、各自做什么）
- Hook 与事件策略
- 测试策略（用哪种测试类型、测什么）
可交给 writing-plans 做详细实现计划，或交给 @drupal-builder 直接实现。
限制与暂未提供的信息
资料未提供安装方式、运行环境要求、收费与授权信息，以上内容暂未提供。