拆分 setup 逻辑的核心是按业务职责归类、保持状态与行为自然耦合。应按功能域提取 composable 函数（如 usesearch、usepagination），统一存放于 src/composables/，命名带 use 前缀；每个函数专注单一语义单元，内聚强关联状态与逻辑，避免无关状态混杂；函数间通过参数传递依赖，不共享 ref；文件按业务或通用性分层组织，拒绝大杂烩式聚合。
拆分 setup 里的庞大逻辑，核心不是“切得越细越好”，而是按业务职责归类、保持状态与行为的自然耦合，让每个函数管好自己的一块事。
按功能域提取 composable 函数
把原本堆在 setup 里混杂的逻辑，识别出独立的功能模块，比如“搜索”“分页”“表单校验”“权限判断”，各自封装成一个函数。这些函数统一放在 src/composables/ 下，命名带 use 前缀（如 useSearch、usePagination）。
- 每个函数内部只处理本职：声明响应式变量、定义副作用（watch）、调用 API、返回必要状态和方法
- 函数之间不直接依赖，靠参数传递必要输入（比如 useSearch 接收一个 fetchResults 函数作为参数，而非硬编码 axios 调用）
- 避免把毫无关联的状态塞进同一个函数——比如把“用户信息”和“图表尺寸”强行合在一个 useCommon 里
保持内聚，拒绝过度拆分
强关联的状态和逻辑必须放一起。例如分页必然涉及 page、pageSize、total 和 changePage 方法，它们属于同一语义单元，就该统一由 usePagination 管理。
- 如果两个 ref 总是一起被读写、一起被重置，说明它们属于同一关注点，不该拆到不同函数中
- 一个函数控制多个相关状态，比十个函数各管一个 ref 更清晰、更易维护
- 拆分粒度以“能独立测试、能跨组件复用、能一眼看出用途”为合理边界
组件内组合多个函数，显式声明依赖
在组件的 setup 中，直接导入并调用这些函数，用解构获取所需变量和方法，再统一 return 给模板使用。
- 每个函数返回的对象结构尽量稳定，比如都返回 { loading, error, refresh } 这类语义化字段
- 不推荐在 setup 里做二次加工（如把多个函数返回的 loading 合并成一个），这会模糊职责边界
- 需要跨函数通信时，优先通过参数传入回调或事件函数，而不是共享 ref 或用 provide/inject
从文件组织上落实模块化
每个 composable 对应一个独立的 .js 文件，文件名即函数名（useSearch.js），导出默认函数。目录结构可按业务或通用性分层：
- src/composables/common/：表单校验、日期格式化、防抖等通用能力
- src/composables/modules/：订单管理、用户列表、报表配置等业务模块专属逻辑
- 避免把所有函数塞进一个 useUtils.js，那只是换种方式的“大杂烩”
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
