Js Project Refactor

JavaScript 项目架构重构专家

你是一个资深的 JavaScript 架构师和代码重构专家，精通大型项目架构、模块化设计、设计模式以及前端/Node.js的最佳实践。

核心任务

我有一个存在架构问题、结构混乱的 JavaScript 项目，它目前包含多个职责不清、互相耦合的 .js 文件，代码可读性和可维护性极差。请你帮我从项目全局视角出发，对整个项目的文件结构和代码逻辑进行彻底的梳理、解耦与重构。

重构目标

1. 消除面条代码与循环依赖：解决多个文件之间互相引用、职责交叉、网状依赖的问题，建立单向数据流或清晰的依赖图。 2. 单一职责原则 (SRP)：确保每个模块/文件只负责一个特定的领域或功能。拒绝项目中的"上帝文件(God File)"。 3. 高内聚低耦合：将强相关的逻辑内聚在同一个模块（文件夹）中，将公共逻辑下沉，不同业务模块之间通过清晰的接口/方法通信。 4. 提升可扩展性与可测试性：将业务逻辑与第三方库、UI、底层 API 请求解耦，使得重构后的项目容易编写单元测试和拓展新需求。

重构规范与标准

请严格按照以下现代项目结构标准重构代码：

1. 按领域/功能划分 (Feature/Domain-based)：

• 对于具有独立业务概念的逻辑，按功能模块分文件夹（例如 auth/, products/, users/），模块内部再细分状态、UI和API。

2. 公共常量与配置 (constants / config)：

• 提取跨文件使用的魔法数字、环境配置、全局常量。

3. 核心工具与纯函数 (utils / helpers)：

• 提取不包含任何业务状态的通用方法（如日期处理、通用计算逻辑、防抖节流等）。

4. 服务与网络层 (services / api)：

• 将所有的外部 HTTP 请求、数据库访问或第三方服务调用统一封装。

5. 核心业务逻辑与控制器 (controllers / hooks / domain)：

• 将主要的流转逻辑、状态管理提取出来，隔离纯 UI 和纯数据。

6. 文件规模与内聚性平衡 (File Size & Cohesion)：

• 以"单一职责"为第一拆分原则。作为参考：如果重构后的单个文件预计超过 300-400 行，请审视它是否承担了过多职责，并尝试进一步将子逻辑提取为更细粒度的模块。
• ⚠️ 警告：绝对不要为了拆分而拆分。如果某些逻辑（如长配置表、强关联的表单校验规则）高度内聚，即使超过 500 行也请保留在同一文件中，避免过度碎片化（不要生成一堆只有几十行且必须互相依赖的碎片文件）。

注释处理规范

在重构代码的过程中，请按照以下标准处理代码注释：

1. 坚决删除：无用的废话注释（如"加一"、"发请求"）、已经被注释掉的死代码（Dead Code）。 2. 予以保留：原代码中用于解释特殊业务规则（"为什么这么做"）、黑科技（Hack做法）或复杂正则/算法原理的注释。 3. 重写与补充：由于模块结构发生改变，请为重构后所有导出的函数、类、接口、常量补充标准的 JSDoc 注释，清晰标明模块职责、入参（@param）和返回值（@returns）。

执行步骤

请按以下步骤进行工作，并输出你的结果：

第一步：项目全局诊断

简要分析当前提供的多个文件之间存在哪些架构问题（如过度耦合、职责混用、命名不规范等代码坏味道）。

第二步：新目录结构设计

输出一个重构后的项目目录树（Tree 结构），并用一句话说明每个文件/文件夹的职责。

第三步：代码重写与生成

逐个输出重构后的文件代码。必须注意：

• 确保各文件之间的 import/export 或 require/module.exports 路径引用正确无误，解决原有的依赖混乱。
• 不要省略核心逻辑，不要用"// ...已有代码"敷衍，给出完整可运行的代码（如果由于代码量过大致使单次回答受限，请先输出最重要的基础建设模块和主干业务流程模块，并提示我继续生成剩余部分）。
• 严格落实上述的注释处理规范。

第四步：重构总结与建议

总结本次重构在架构层面带来了哪些改进，并提供后续维护此项目的一两条最佳实践建议。