制定了前端项目的标准目录结构规范独立编写 ESLint 配置文件实现代码风格统一引入 Husky 与 lint-staged通过 Git 钩子拦截不合规代码核心目录结构设计我按照功能模块化和文件类型相结合的方式划分了 src 目录具体结构如下src/api/ 存放 Axios 实例及各模块的接口请求方法src/components/ 存放全局可复用的无状态 UI 组件src/pages/ 存放业务相关的页面容器组件src/store/ 存放 Zustand 状态管理的各个分片src/types/ 存放全局 TypeScript 类型声明文件这种划分方式既保持了按功能查找的便利性又确保了不同类型文件的清晰分离。ESLint 规则配置为了保证团队代码风格一致我独立编写了 ESLint 配置文件集成了 TypeScript 和 React Hooks 的校验规则。核心配置如下module.exports {root: true,env: { browser: true, es2020: true },extends: [eslint:recommended,plugin:typescript-eslint/recommended,plugin:react-hooks/recommended,],ignorePatterns: [dist, .eslintrc.cjs],parser: typescript-eslint/parser,plugins: [react-refresh],rules: {react-refresh/only-export-components: [warn,{ allowConstantExport: true },],typescript-eslint/no-explicit-any: warn,typescript-eslint/no-unused-vars: error,no-console: [warn, { allow: [warn, error] }]},}规则说明限制 any 类型的使用会给出警告未使用的变量会报错生产环境中禁止使用 console.log 但允许 warn 和 error。Prettier 与代码格式化除了 ESLint 的语法检查我还配置了 Prettier 进行代码格式化确保缩进、引号、分号等风格统一。两者配合使用ESLint 负责代码质量Prettier 负责代码格式。Husky 与 lint-staged 拦截提交为了保证提交到仓库的代码都是符合规范的我配置了 Husky在 Git pre-commit 阶段自动执行代码格式化和检查。在 package.json 中添加了如下配置{scripts: {prepare: husky install,lint: eslint . --ext ts,tsx --report-unused-disable-directives --max-warnings 0},lint-staged: {.{ts,tsx}: [eslint --fix,prettier --write],.{css,scss,json,md}: [prettier --write]}}工作流程开发者执行 git commit 时lint-staged 会针对暂存区的文件运行 ESLint 自动修复和 Prettier 格式化。如果代码存在无法自动修复的错误提交会被拦截直到问题解决。总结通过这套从目录规范到代码检查的完整体系建立了一个可维护、可扩展的前端工程基础。清晰的目录结构降低了代码查找成本ESLint 和 Prettier 保证了代码风格的一致性而 Husky 配合 lint-staged 则在提交环节形成了最后一道防线彻底杜绝了不规范代码进入版本库。