setup 中应按“功能闭环”切分业务逻辑，每个模块以 use+动词命名、只做一件事、自包含状态与副作用、精简入参、独立运行、自动初始化与清理、扁平化返回、typescript 显式类型、组合时注重输入输出串联。
在 setup 中写清晰、可复用的业务逻辑，关键不是堆砌 ref 和方法，而是按“功能闭环”切分——每个模块负责一个完整能力，从状态、计算、副作用到行为全部自包含。
按业务动词命名和封装模块
模块名以 use 开头，后接动词短语，直指用途，比如 useSearch、useFormValidation、usePagination。避免笼统命名如 useUtils 或 useCommon。
- 每个模块只处理一件事：搜索就管搜索状态、关键词、防抖、请求和结果；分页就管当前页、总条数、跳转、加载中状态
- 不暴露内部实现细节，只返回组件真正需要的响应式变量和函数
- 入参尽量精简，优先接收必要配置（如 API 函数、初始值），而非整个上下文对象
模块内保持逻辑自洽与低耦合
一个模块应能独立运行，不依赖外部 setup 的变量或生命周期钩子。它自己处理初始化、监听、清理等环节。
- 用
onMounted或watchEffect自动触发首次动作，而不是让调用方手动调用init() - 副作用（如定时器、事件监听）在
onUnmounted中主动清除，避免内存泄漏 - 若需访问路由、全局状态等，通过参数注入（如
useSearch({ router, store })），不直接 import 或使用getCurrentInstance
导出时统一结构，便于解构使用
模块返回的对象结构应稳定、语义明确，常用字段包括：state（响应式数据）、actions（操作函数）、computed（派生状态），或直接平铺为扁平属性。
- 推荐扁平返回：简洁直观，模板中可直接解构使用，例如
const { query, results, search, isLoading } = useSearch(fetchApi) - 避免嵌套过深：不返回
{ data: { items: ref([]) } }这类结构，除非有明确分组需求 - 类型上用 TypeScript 显式标注返回值，尤其对函数参数和响应式字段做精确约束
在组件中组合多个模块，不拼凑逻辑
setup 不是“把所有模块 import 进来然后 return”，而是有意识地串联它们的输入输出关系。
- 例如：表单校验模块的
isValid可作为提交按钮的禁用依据；搜索模块的query可作为过滤列表的输入源 - 避免跨模块直接修改对方的 ref，改用事件式通信（如回调函数）或状态提升（由父模块统一管理）
- 多个模块共用同一份数据时，考虑将该数据提取为独立模块（如
useUserSession），其余模块依赖它
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
