Fusion UI 组件开发

业务页面开发的重复造轮子困境

在使用 Fusion 模板开发前端业务页面时，团队面临一个常见的工程效率陷阱：开发者容易在既有的运行时基版之上，重新实现组件注册、Axios 拦截器、Token 与租户请求头注入、动态路由、权限加载以及系统参数初始化。这种重复造轮子的行为不仅增加了维护成本，还容易导致不同模块间的代码风格和组件使用规范不一致。此外，面对繁杂的 fs-form、fs-table 等平台组件，开发者往往需要反复确认标签、配置属性和表格列的组件类型，耗费大量时间在文档检索上。

基于基版的按需开发规范

为了解决上述问题，@user_40e432fa/fusion-ui 技能将 template-ui 视为完全集成的运行时基版。它的核心能力在于引导开发者遵循“编码式配置”和平台组件优先的原则，避免在无明确需求时触碰框架底层逻辑。

该技能的工作流程强调上下文管理与一致性：

• 任务分级与按需阅读：首先判断任务属于基版集成、接口开发、组件配置还是完整页面开发，随后只读取匹配的参考文档（如 references/router.md、references/api-request.md），避免无关规范占用上下文。
• 状态与接口约定：通过 @/api 中的 $get、$post 等封装方法请求接口；从 this.$store.state.app 读取系统参数，从 this.$store.state.permission 获取用户和权限状态。
• 页面对齐：开发前查看目标项目附近的页面，确保本模块的命名、接口文件、按钮文案和交互风格与现有代码保持一致。

适用边界与工程注意事项

该技能明确划定了开发边界：禁止随意重写框架层能力，除非用户明确要求。在处理业务 ID 时，必须按字符串原样透传，严禁使用 Number 或 parseInt 转换。接口失败应交由全局请求拦截器处理，页面仅关注成功流程、前置校验和必要的 finally 收尾。

当不确定平台组件的标签、属性名或配置是否存在时，必须先查阅组件 API 索引。虽然技能提供了丰富的 CRUD、树列表、弹窗表单等示例资产，但在生产环境中使用这些示例时，必须严格替换为目标项目的字段名、接口路径和业务规则，而非直接照搬。