单文件组件（SFC）的模块划分本质取决于 script 中的设计思路，而非文件形式本身；应通过组合式函数按功能域抽离逻辑、语义化分组代码、角色化区分职责，并借助 TypeScript 与工具链强化边界。
单文件组件（SFC）本身不是一种编程范式，而是一种文件组织形式；它承载的模块划分逻辑，取决于你如何组织 <script> 中的代码结构和依赖关系。真正的模块划分范式，来自你在 script 部分采用的设计思路——比如逻辑拆分、关注点分离、可复用性抽象等。
按功能域划分逻辑模块
将与组件强相关的业务逻辑（如表单校验、数据转换、状态计算）抽离为独立函数或组合式函数（Composable），而非堆砌在 setup 或 data 中。这样既保持 SFC 的完整性，又实现逻辑复用。
- 例如：把“用户登录流程”封装成
useLogin()，内部管理 loading、error、submit 行为，返回响应式状态和操作方法 - 避免在 script 标签里直接写 axios 调用或 localStorage 操作，统一由组合函数封装并测试
- 组合函数可存于
composables/目录，按功能命名（useFilters、usePagination），不绑定具体组件
按生命周期或响应式阶段组织代码块
在 <script setup> 中，通过语义化分组提升可读性，属于隐性的模块划分实践。这不是语法要求，而是团队约定的结构范式。
- 顶部声明响应式基础（ref、reactive、props、emits）
- 中间定义计算属性与侦听器（computed、watch、watchEffect）
- 底部集中导出方法（函数需明确副作用边界，如只触发 emit 或更新局部 ref）
- 不混写逻辑：比如不在 watch 里发请求，改用事件回调或组合函数统一处理
按运行时角色区分模块职责
一个 SFC 的 script 可视作由多个“角色模块”协同工作：状态模块（data）、行为模块（methods）、联动模块（watch/computed）、集成模块（onMounted/onUnmounted）。合理划分能降低耦合。
立即学习“Java免费学习笔记（深入）”；
- 状态模块专注数据初始值与响应式结构，不掺杂副作用
- 行为模块函数应是纯的或有明确定义的副作用（如调用 api、修改 dom、触发事件）
- 联动模块只负责响应变化，不主动发起变更；变化引发的动作交给行为模块
- 集成模块仅做“连接”，比如 onMounted 中调用初始化函数，而非把初始化逻辑全写在里面
配套工具强化模块边界
借助 TypeScript 类型 + ESLint 规则 + 自定义 Volar 插件，可让模块划分从“自觉习惯”变成“强制约束”。
- 用
defineProps<T>()和defineEmits<E>()显式声明接口，形成组件契约 - 禁用
any和隐式any，确保组合函数输入输出类型清晰 - 配置 ESLint 规则（如
@typescript-eslint/no-unused-vars）自动清理未使用的逻辑块 - 在
compilerOptions.types中引入自定义类型声明，让组合函数支持自动导入提示
