模块拆分应按业务域组织目录并设index统一导出，禁止跨域直接导入内部文件；状态管理依场景选Redux Toolkit（跨层/复杂副作用）或Context+useReducer（局部高频共享）；构建时正确引入支持tree-shaking的库并验证打包结果；单元测试聚焦纯逻辑、状态转换、API解析及Hook契约，不测渲染、第三方调用或实现细节。
大型项目里模块怎么拆才不互相污染
JavaScript 项目一旦超过 50 个文件，靠全局变量或随意 import 就会迅速失控。核心原则是「显式依赖 + 边界隔离」：每个模块只暴露必要接口，内部实现不透出，且所有依赖必须在顶部 import 声明。
实操建议：
- 按业务域（如
user、payment）而非技术类型（如components、utils）组织目录，避免跨域逻辑散落 - 每个域内设
index.ts统一导出对外 API，禁止外部文件直接导入该域内部的helpers/或adapters/ - 用 TypeScript 的
declare module或打包工具的externals阻断意外依赖，比如防止 UI 层直接调用数据库 client
状态管理什么时候该用 Redux Toolkit，什么时候该用 Context + useReducer
不是所有状态都需要进全局 store。Redux Toolkit 适合跨多层组件、需时间回溯、有复杂副作用（如请求重试、离线队列）的状态；Context + useReducer 更适合局部但共享频繁的状态，比如表单编辑态、主题切换。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
- 把
useState提升到顶层 Context 导致整个应用重渲染 - 用 Redux 管理仅两个组件间传递的临时筛选参数，增加 action/type/selector 三层冗余
- 忘记给 Redux slice 设置
extraReducers处理异步生命周期，导致 loading 状态不同步
判断依据：如果某个状态变化后，你得打开 4 个以上文件去改 mapStateToProps 或 useSelector，说明它大概率不该放全局。
构建时如何避免 node_modules 里的包被重复打包
Webpack 或 Vite 默认会把 node_modules 全部打进 bundle，但像 lodash-es、date-fns 这类支持 tree-shaking 的库，若引入方式不对，整包都会保留。
ISite企业建站系统是为懂点网站建设和HTML技术的人员（例如企业建站人员）而开发的一套专门用于企业建站的开源免费程序。本系统采用了全新的栏目维护模式，内容添加过程中，前后台菜单是一样的，需要维护前台某个栏目的内容，只需要进后台相应栏目即可，一般的企业人员只需要查看简易的说明就可以上手维护网站内容。通过自由度极高的模板系统，可以适应大多数情况的界面需求，后台带有标签生成器，建站只需要构架好HTM
关键参数差异：
- 用
import { debounce } from 'lodash-es'而非import _ from 'lodash-es'—— 后者无法摇掉未用方法 - Vite 项目检查
vite.config.ts中是否误配了optimizeDeps.include，把本可 external 的包强制预构建 - Webpack 用户注意
resolve.alias是否指向了未编译的源码目录（如react-dom/profiling），这会让整个react-dom进入打包
验证方法：构建后运行 npx source-map-explorer dist/assets/*.js，看是否有大块第三方库未被拆分。
测试边界在哪里：单元测试该测什么，不该测什么
单元测试不是覆盖率数字游戏。重点覆盖：纯函数逻辑、状态转换规则、API 响应解析器、自定义 Hook 的输入输出契约。不测：React 组件渲染结果（交给 E2E）、第三方 SDK 调用（mock 掉）、CSS 类名拼接。
容易踩的坑：
- 给
fetch写真实网络请求测试，CI 环境失败率飙升 - 在测试里写
expect(wrapper.find('button').length).toBe(1)—— 这属于实现细节，组件重构换标签就崩 - 没 mock
Date.now()或Math.random()，导致测试随机失败
真正可维护的测试，是当你删掉一个函数后，只有 1–2 个测试报错，且错误信息直指该函数的契约破坏点。
