核心用法
Storybook 采用 Component Story Format (CSF) 作为标准写作规范，每个 .stories.tsx 文件包含：
- 默认导出（meta）：定义组件标题、元数据、全局
args和decorators - 具名导出：每个导出对象即为一个独立 story，通过
args传入 props
Args 与 Controls 体系：args 是实际传入组件的 prop 值，argTypes 则配置控制面板的 UI 类型（如 select、color、boolean）。TypeScript 类型会自动推断控件类型，大幅减少配置工作量。
Decorators 与 Context：用于包裹 Provider、主题或布局容器，支持组件级和全局级（.storybook/preview.js），执行顺序为从内到外嵌套。
Play Functions（交互测试）：在浏览器中执行真实用户交互，结合 @storybook/testing-library 实现点击、输入、断言等操作，替代传统单元测试的静态渲染。
显著优点
- 开发体验卓越：热更新、隔离渲染、自动生成 Props 文档，文档与代码同源
- TypeScript 深度集成：
satisfies Meta<typeof Component>提供完整类型推导，控件从类型自动生成 - 可视化回归测试：配合 Chromatic 或 Storybook Test Runner 实现 UI 快照对比
- 生态系统成熟：3000+ 社区 addon，支持 A11y 测试、响应式预览、MSW mock 等
- CI/CD 友好：可导出静态站点，作为设计系统文档站点托管
潜在缺点与局限性
- 构建开销：大型项目启动 Storybook 耗时较长，内存占用高于普通开发服务器
- 版本迁移成本：CSF2 到 CSF3、Storybook 6 到 7/8 的 Breaking Changes 较多，升级需批量改写 stories
- 测试局限性：Play functions 运行在浏览器环境，不适合纯逻辑函数的单元测试；复杂异步流调试困难
- 配置碎片化：
.storybook/main.js、.storybook/preview.js、项目根配置分散，新手易混淆
适合人群
- 前端组件库/设计系统维护者：需要标准化文档与交互演示
- 中大型团队：多人协作需统一组件使用范例与视觉回归基线
- 全栈开发者：快速验证边界状态（Empty/Loading/Error）而无需完整页面上下文
常规风险
- 依赖冲突：Webpack/Vite 版本与 Storybook 内置配置可能冲突，需
webpackFinal自定义调整 - Mock 数据泄漏：Play functions 中未清理的 MSW handler 可能污染后续 story
- 性能劣化：大量 stories 未配置
tags: ['!autodocs']会导致构建产物膨胀 - 类型漂移：组件 props 变更后若未及时更新
argTypes，Controls 面板显示 stale 类型