创新项目实训记录（三）
制定了前端项目的标准目录结构规范
独立编写 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 则在提交环节形成了最后一道防线，彻底杜绝了不规范代码进入版本库。