@chenhui996/gg-cli 1.0.4 → 1.0.6

package/dist/template/zhiguan/.editorconfig

@@ -0,0 +1,16 @@
+# EditorConfig is awesome: https://EditorConfig.org
+
+# top-most EditorConfig file
+root = true
+
+# Unix-style newlines with a newline ending every file
+[*]
+end_of_line = lf
+insert_final_newline = true
+charset = utf-8
+trim_trailing_whitespace = true
+indent_style = space
+indent_size = 2
+
+[*.md]
+trim_trailing_whitespace = false

package/dist/template/zhiguan/.env

@@ -0,0 +1 @@
+VITE_API_BASE_URL=/api

package/dist/template/zhiguan/.env.development

@@ -0,0 +1,4 @@
+# 开发环境配置
+VITE_ENV=development
+VITE_API_BASE_URL=/api
+VITE_APP_TITLE=Operations Template (Dev)

package/dist/template/zhiguan/.env.production

@@ -0,0 +1,4 @@
+# 生产环境配置
+VITE_ENV=production
+VITE_API_BASE_URL=https://api.example.com
+VITE_APP_TITLE=Operations Template

package/dist/template/zhiguan/.env.test

@@ -0,0 +1,4 @@
+# 测试环境配置
+VITE_ENV=test
+VITE_API_BASE_URL=https://test-api.example.com
+VITE_APP_TITLE=Operations Template (Test)

package/dist/template/zhiguan/.prettierignore

@@ -0,0 +1,34 @@
+# 忽略格式化的目录和文件
+node_modules
+dist
+build
+coverage
+
+# 忽略特定类型的文件
+*.png
+*.jpg
+*.jpeg
+*.gif
+*.svg
+*.ico
+*.eot
+*.ttf
+*.woff
+*.woff2
+*.mp4
+*.webm
+*.ogg
+*.mp3
+*.wav
+*.flac
+*.aac
+
+# 忽略锁定文件
+package-lock.json
+yarn.lock
+pnpm-lock.yaml
+
+# 其他忽略
+.DS_Store
+.idea
+.vscode

package/dist/template/zhiguan/.prettierrc

@@ -0,0 +1,14 @@
+{
+  "printWidth": 100,
+  "tabWidth": 2,
+  "useTabs": false,
+  "semi": true,
+  "singleQuote": true,
+  "quoteProps": "as-needed",
+  "jsxSingleQuote": false,
+  "trailingComma": "all",
+  "bracketSpacing": true,
+  "bracketSameLine": false,
+  "arrowParens": "always",
+  "endOfLine": "lf"
+}

package/dist/template/zhiguan/README.md

@@ -0,0 +1,183 @@
+# Operations Template (运营后台模版)
+
+基于 React 19 + TypeScript + Vite 8 + Ant Design 6 的现代化后台管理系统模版。
+本模版专为快速构建企业级中后台应用而设计，集成了最佳实践的工程化配置、清晰的架构分层和美观的 UI 设计。
+
+## ✨ 特性与架构
+
+- **最新技术栈**: 采用 React 19、Vite 8、TypeScript 5 等前沿技术。
+- **UI 设计**: 集成 Ant Design 6，配合 Less 预处理器，深度还原企业级设计规范。
+- **状态管理**: 使用 Zustand 5 进行轻量级全局状态管理，告别繁琐的 Redux 样板代码。
+- **路由管理**: 基于 React Router 7.x 的 Data API 路由模式，支持更细粒度的路由控制。
+- **网络请求**: 封装 Axios 1.x，统一处理拦截器、错误码和 TypeScript 类型定义。
+- **工程化与规范**: 配置 ESLint 9 (逻辑检查) 与 Prettier (代码格式化)，并集成 EditorConfig 统一跨编辑器基础风格。
+- **多环境支持**: 完善的 `.env` 环境隔离机制，清晰区分开发 (dev)、测试 (test) 和生产 (prod) 环境。
+- **生产构建优化**: 内置产物分类、第三方依赖 (Vendor) 手动分包策略、自动剔除 Console 等生产级优化。
+
+## 📦 目录结构
+
+```bash
+src/
+├── api/                # API 接口定义层
+│   └── user.ts         # 用户相关接口示例
+├── assets/             # 静态资源文件 (图片、图标等)
+├── components/         # 公共组件库
+│   └── Chart/          # ECharts 图表组件封装
+├── layouts/            # 布局组件
+│   └── BasicLayout.tsx # 基础布局 (侧边栏 + 顶栏 + 内容区)
+├── pages/              # 页面组件 (路由视图)
+│   ├── home/           # 首页 (包含欢迎语、搜索、快捷功能、任务列表)
+│   ├── dashboard/      # 数据看板 (ECharts 示例)
+│   └── about/          # 关于页面
+├── router/             # 路由配置
+│   └── index.tsx       # 路由表定义
+├── store/              # 全局状态管理 (Zustand)
+│   └── useCounterStore.ts
+├── utils/              # 工具函数
+│   └── request/        # Axios 二次封装
+├── main.tsx            # 应用入口
+├── App.tsx             # 根组件
+└── vite-env.d.ts       # Vite 环境变量类型声明
+```
+
+## 🚀 快速上手
+
+### 1. 环境准备
+
+确保您的本地环境已安装 Node.js (推荐 v18+)。
+
+### 2. 安装依赖
+
+```bash
+npm install
+# 或者
+yarn
+# 或者
+pnpm install
+```
+
+### 3. 启动开发服务器
+
+```bash
+npm run dev
+```
+
+浏览器访问 `http://localhost:5173` 即可看到效果。
+
+### 3. 构建生产环境
+
+```bash
+# 构建测试环境
+npm run build:test
+
+# 构建生产环境
+npm run build:prod
+# 或
+npm run build
+```
+
+## 🛠 开发与构建指南
+
+### 1. 环境变量配置
+
+项目根目录包含三个环境配置文件，利用 Vite 的 `import.meta.env` 进行读取，且内置了完整的 TypeScript 类型提示：
+- `.env.development`：本地开发环境 (运行 `npm run dev` 时加载)
+- `.env.test`：测试环境 (运行 `npm run build:test` 时加载)
+- `.env.production`：生产环境 (运行 `npm run build:prod` 时加载)
+
+> 💡 **注意**：在代码中可以通过 `import.meta.env.VITE_XXX` 访问环境变量。为了安全，所有暴露给前端的自定义环境变量必须以 `VITE_` 开头。
+
+### 2. 代码检查与格式化
+
+```bash
+# 运行 ESLint 逻辑检查
+npm run lint
+
+# 运行 Prettier 格式化代码 (将会自动格式化 src 目录下的文件)
+npm run format
+```
+
+### 3. 生产环境构建与优化
+
+本项目针对生产环境 (`build:prod`) 做了深度优化，确保上线的资源体积最小、加载最快：
+- **静态资源 Hash 分类**：JS、CSS、图片等资源分别打包到不同的文件夹，并打上 Hash 戳，完美配合服务器的强缓存策略。
+- **手动分包 (Manual Chunks)**：将体积巨大且变动极少的第三方依赖（如 `react` 核心库、`antd` 组件库、`echarts` 图表库）单独拆分。这样即便你修改了业务代码，用户依然能命中第三方库的浏览器缓存。
+- **代码净化**：自动剔除代码中的 `console` 和 `debugger` 语句，提升性能并保护代码安全。
+
+### 4. 构建产物分析 (打包体积分析)
+
+如果你想了解每个包（Chunk）的体积大小，排查是否引入了臃肿的依赖，可以运行分析脚本：
+
+```bash
+npm run analyze
+```
+该命令会自动执行生产环境构建，并在打包结束后，于浏览器中弹出一个 **交互式的可视化树状图** (`dist/stats.html`)，让你对所有产物的原始大小和 Gzip 压缩大小一目了然。
+
+---
+
+## 💻 业务开发指南
+
+### 1. 新增页面
+
+1. 在 `src/pages` 下新建文件夹，例如 `src/pages/product`。
+2. 创建 `index.tsx` 并导出默认组件。
+3. 在 `src/router/index.tsx` 中配置路由规则。
+
+### 2. 样式开发
+
+项目支持 **Less** 预处理器。
+- **全局样式**: 修改 `src/index.css` 或配置 `src/main.tsx` 中的 Ant Design Token。
+- **组件样式**: 推荐使用 `.less` 文件，并在组件中引入。
+  ```less
+  // src/pages/home/index.less
+  .home-page {
+    padding: 20px;
+  }
+  ```
+
+### 3. 网络请求
+
+使用 `src/utils/request` 中导出的 `request` 实例。
+
+```typescript
+import { request } from '@/utils/request';
+
+// 定义响应类型
+interface UserInfo {
+  id: number;
+  name: string;
+}
+
+// 发起请求
+const getUser = () => {
+  return request.get<UserInfo>('/api/user/1');
+};
+```
+
+### 4. 状态管理 (Zustand)
+
+```typescript
+import { create } from 'zustand';
+
+interface UserState {
+  name: string;
+  setName: (name: string) => void;
+}
+
+export const useUserStore = create<UserState>((set) => ({
+  name: 'Guest',
+  setName: (name) => set({ name }),
+}));
+
+// 在组件中使用
+const { name, setName } = useUserStore();
+```
+
+## 🎨 设计规范
+
+- **主色调**: `#4F46E5` (Indigo)
+- **圆角**: 全局组件圆角 `8px`，卡片圆角 `12px`
+- **布局**: 左侧固定侧边栏 (`240px`) + 顶部通栏
+- **图标**: 使用 `@ant-design/icons`
+
+---

package/dist/template/zhiguan/docs/Git/345/274/200/345/217/221/350/247/204/350/214/203.md

@@ -0,0 +1,105 @@
+# Git 开发规范
+
+为了保证团队协作的高效性、代码历史的可追溯性以及发布流程的稳定性，特制定本 Git 开发规范。团队成员需严格遵守本规范进行代码的分支管理和提交。
+
+## 1. 分支管理模型
+
+我们采用基于 Git Flow 思想的轻量级分支管理模型。
+
+### 1.1 长期分支
+- **`main` (或 `master`)**: 主分支。
+  - 只能包含稳定、已发布或即将发布到生产环境的代码。
+  - **严禁直接在 `main` 分支上进行开发提交**。
+  - 所有合并到 `main` 的代码必须经过 Code Review 和充分测试。
+- **`develop`**: 开发主分支。
+  - 包含下一个版本将要发布的所有最新代码。
+  - 从 `main` 分支拉取，功能分支合并回此分支。
+  - 部署到**开发/测试环境**的基础分支。
+
+### 1.2 临时分支
+临时分支用完即删，保持分支列表整洁。
+
+- **`feature/*` (功能分支)**:
+  - 命名规范：`feature/功能名称` 或 `feature/需求ID-功能名称` (如：`feature/login-page`, `feature/JIRA-123-user-profile`)。
+  - 从 `develop` 分支拉取。
+  - 开发完成后合并回 `develop` 分支。
+- **`bugfix/*` (缺陷修复分支)**:
+  - 命名规范：`bugfix/问题描述` 或 `bugfix/缺陷ID-问题描述` (如：`bugfix/login-crash`, `bugfix/JIRA-456-table-render-error`)。
+  - 用于修复日常测试中发现的非紧急 Bug。
+  - 从 `develop` 分支拉取，修复后合并回 `develop`。
+- **`hotfix/*` (线上紧急修复分支)**:
+  - 命名规范：`hotfix/问题描述` 或 `hotfix/缺陷ID` (如：`hotfix/payment-failure`)。
+  - **仅用于修复生产环境的严重 Bug**。
+  - 必须从 `main` 分支拉取！
+  - 修复测试通过后，**必须同时合并回 `main` 和 `develop` 分支**，并在 `main` 上打上新版本 Tag。
+
+## 2. Commit 提交规范
+
+我们遵循 [Angular Commit 规范](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines)，使用标准化的格式来记录每一次提交，以便自动生成 Changelog 并快速定位问题。
+
+### 2.1 Commit Message 格式
+```text
+<type>(<scope>): <subject>
+// 空一行
+<body>
+// 空一行
+<footer>
+```
+
+### 2.2 Type (必填)
+说明本次提交的类型，只允许使用以下标识：
+- `feat`: 新增功能 (Feature)
+- `fix`: 修复 Bug
+- `docs`: 仅修改文档 (Documentation)
+- `style`: 仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑 (不涉及逻辑的格式修改)
+- `refactor`: 代码重构，没有加新功能或者修复 bug
+- `perf`: 优化相关，比如提升性能、体验
+- `test`: 增加测试，包括单元测试、集成测试等
+- `build`: 影响构建系统或外部依赖的更改（如：webpack, npm）
+- `ci`: 对 CI 配置文件和脚本的更改
+- `chore`: 构建过程或辅助工具的变动
+- `revert`: 回滚到上一个版本
+
+### 2.3 Scope (选填)
+用于说明本次 Commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。例如在前端项目中，可以是具体的页面或组件名：`auth`, `table-component`, `router` 等。
+
+### 2.4 Subject (必填)
+本次提交的简短描述，不超过 50 个字符。
+- 以动词开头，使用第一人称现在时，比如 `change`，而不是 `changed` 或 `changes`。
+- 首字母小写。
+- 结尾不加句号 (`.`)。
+
+### 2.5 Body (选填)
+对本次提交的详细描述，可以分成多行。说明代码变更的动机，以及与之前行为的对比。
+
+### 2.6 Footer (选填)
+- **不兼容变动 (Breaking Changes)**：如果当前代码与上一个版本不兼容，则 Footer 部分以 `BREAKING CHANGE:` 开头，后面是对变动的描述、以及变动理由和迁移方法。
+- **关闭 Issue/缺陷**：如果当前 commit 针对某个 issue/需求，那么可以在 Footer 部分关闭这个 issue。如：`Closes #123`, `Fixes JIRA-456`。
+
+### 2.7 Commit 示例
+```text
+feat(user): 新增用户登录页面的记住密码功能
+
+增加了本地 storage 的存储逻辑，在用户勾选记住密码时，加密保存 token。
+
+Closes #89
+```
+
+```text
+fix(table): 修复数据为空时分页器仍然显示的问题
+```
+
+## 3. 工作流与 Code Review 规范
+
+1. **同步最新代码**：每天开发前，或在拉取新分支前，务必先 `git pull --rebase origin develop`，确保基于最新代码开发。
+2. **小步提交**：鼓励频繁提交本地代码（遵循 Commit 规范），避免将几天的巨大工作量堆积在一次 Commit 中。
+3. **合并前 Rebase**：在将功能分支合并回 `develop` 之前，如果 `develop` 已经有了新的提交，建议在自己的分支上先执行 `git rebase develop`，解决冲突后再发起 Merge Request / Pull Request。这有助于保持线性的提交历史。
+4. **Code Review (CR)**：
+   - 合并代码到 `develop` 或 `main` 必须通过发起 PR/MR 的方式，**禁止直接 Push**。
+   - 至少需要一位其他开发人员 Review 通过 (Approve) 后才能合并。
+   - CR 重点关注：代码是否符合规范、是否有潜在 Bug、性能是否达标、是否包含敏感信息（如明文密码、密钥）。
+
+## 4. 辅助工具推荐
+强烈建议在项目中集成以下工具以保证规范的落地：
+- **`husky` + `lint-staged`**：在提交前自动进行 ESLint / Prettier 检查。
+- **`commitlint` + `commitizen`**：在 `git commit` 时强制校验 Commit Message 是否符合规范。

package/dist/template/zhiguan/docs/React/345/274/200/345/217/221/350/247/204/350/214/203.md

@@ -0,0 +1,81 @@
+# React 开发规范
+
+本文档规定了团队内 React 项目的开发规范和最佳实践，旨在提高代码的可读性、可维护性和团队协作效率。
+
+## 1. 组件开发规范
+
+### 1.1 组件定义
+- **统一使用函数组件 (Function Component)**：放弃 Class 组件，全面拥抱 React Hooks。
+- **使用 `React.FC` 定义类型**：结合 TypeScript，明确组件类型。
+- **使用 `Props`**：不直接在函数参数处解构 props，而是通过解构赋值在函数内部获取 props。
+
+```tsx
+// ✅ 推荐做法
+import React from 'react';
+
+interface UserCardProps {
+  name: string;
+  age?: number;
+}
+
+export const UserCard: React.FC<UserCardProps> = (props) => {
+  const { name, age = 18 } = props;
+
+  return (
+    <div>
+      <p>Name: {name}</p>
+      <p>Age: {age}</p>
+    </div>
+  );
+};
+```
+
+### 1.2 命名规范
+- **组件文件命名**：使用 **PascalCase (大驼峰)** 命名（如 `UserProfile.tsx`）。如果组件是一个目录，使用 **pascal-case（kebab-case）**，入口文件使用 `index.tsx`。
+- **组件内部变量/函数命名**：使用 **camelCase (小驼峰)** 命名。
+- **事件处理函数命名**：
+  - 传递给组件的 props 命名为 `onXxx`（如 `onClick`）。
+  - 组件内部的处理函数命名为 `handleXxx`（如 `handleClick`）。
+
+### 1.3 组件结构与拆分
+- **单一职责原则**：一个组件只做一件事情。如果组件逻辑变得复杂，应拆分为更小的子组件。
+- **UI 与逻辑分离**：尽量保持 UI 组件 (Presentational Component) 的纯粹性，将复杂的业务逻辑、数据获取抽离到自定义 Hook 或容器组件 (Container Component) 中。
+
+## 2. Hooks 使用规范
+
+### 2.1 基础 Hooks
+- **`useState`**：用于管理组件内部的简单状态。对于复杂状态，考虑使用 `useReducer` 或全局状态管理库 (如 Zustand)。
+- **`useEffect`**：
+  - 必须明确声明依赖数组 (Dependency Array)。
+  - 避免在 `useEffect` 中执行过多不相关的逻辑，按功能拆分为多个 `useEffect`。
+  - 注意清理副作用 (如定时器、事件监听器)。
+
+### 2.2 性能优化 Hooks
+- **谨慎使用 `useMemo` 和 `useCallback`**：仅在遇到真正的性能瓶颈或需要传递稳定的引用给子组件时使用。过度使用会增加内存开销。
+- 由于项目引入了 React Compiler (React 19)，编译器会自动进行大部分的 Memoization 优化，手动使用这些 Hook 的场景将大幅减少。
+
+### 2.3 自定义 Hooks
+- **命名规范**：必须以 `use` 开头（如 `useFetchUser`）。
+- **返回值**：通常返回一个数组 `[value, setValue]` 或一个对象 `{ data, loading, error }`，根据实际场景决定。
+
+## 3. 状态管理规范
+
+- **局部状态**：优先使用组件内部的 `useState` 或 `useReducer`。
+- **全局状态**：使用 Zustand 5 进行轻量级的全局状态管理。
+  - 按业务模块划分 Store (如 `useUserStore`, `useAppStore`)。
+  - 避免将所有状态都放入全局 Store，只共享真正需要跨组件通信的状态。
+
+## 4. 样式开发规范
+
+- **预处理器**：统一使用 Less。
+- **样式隔离**：
+  - 优先使用 CSS Modules (命名为 `xxx.module.less`)，避免全局样式污染。
+  - 配合 classnames 库进行类名的条件拼接。
+- **命名约定**：Less 文件中的类名使用 **kebab-case (短横线命名法)**，如 `.user-profile-container`。
+
+## 5. 代码质量与格式化
+
+- 必须遵守项目配置的 ESLint 和 Prettier 规则。
+- 在提交代码前，确保没有 ESLint 警告或错误。
+- 避免使用 `any`，尽可能提供准确的 TypeScript 类型定义。
+- 不要保留未使用的变量或导入 (`no-unused-vars`)。

package/dist/template/zhiguan/docs/TypeScript/345/274/200/345/217/221/350/247/204/350/214/203.md

@@ -0,0 +1,119 @@
+# TypeScript 开发规范
+
+本文档旨在统一团队内 TypeScript 的使用方式，提升代码的健壮性和可维护性，减少运行时错误。
+
+## 1. 基础规范
+
+### 1.1 命名规范
+- **接口 (Interface) 和 类型别名 (Type Alias)**：
+  - 使用 **PascalCase (大驼峰)** 命名。
+  - 不要使用 `I` 或 `T` 作为前缀（如 `interface IUser` ❌，应为 `interface User` ✅）。
+- **枚举 (Enum)**：
+  - 使用 **PascalCase** 命名枚举及其成员。
+  - 推荐使用字符串枚举以提高调试时的可读性。
+
+```typescript
+// ✅ 推荐做法
+enum UserRole {
+  Admin = 'ADMIN',
+  Editor = 'EDITOR',
+  Viewer = 'VIEWER',
+}
+```
+
+### 1.2 `interface` vs `type`
+- **优先使用 `interface`**：在定义对象或组件 Props 的形状时，默认使用 `interface`。
+- **使用 `type` 的场景**：当需要使用联合类型 (Union Types)、交叉类型 (Intersection Types) 或映射类型 (Mapped Types) 等高级特性时，才使用 `type`。
+
+```typescript
+// ✅ 推荐做法
+interface User {
+  id: string;
+  name: string;
+}
+
+type ID = string | number; // 联合类型必须用 type
+```
+
+## 2. 组件与 Props 规范
+
+### 2.1 Props 定义
+- **必须为每个组件定义 Props 接口**：命名约定为 `[ComponentName]Props`。
+- **明确可选属性**：使用 `?` 标记可选属性，并为其提供合理的默认值。
+- **避免内联类型定义**：不要在函数签名中直接写出庞大的类型对象。
+
+```tsx
+// ✅ 推荐做法
+interface ButtonProps {
+  label: string;
+  onClick: () => void;
+  disabled?: boolean; // 明确可选
+}
+
+export const Button: React.FC<ButtonProps> = (props) => {
+  const { label, onClick, disabled = false } = props;
+  // ...
+};
+```
+
+### 2.2 事件处理类型
+- 优先使用 React 内置的事件类型（如 `React.MouseEvent<HTMLButtonElement>`、`React.ChangeEvent<HTMLInputElement>`），避免使用 `any`。
+
+```tsx
+// ✅ 推荐做法
+const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
+  console.log(e.target.value);
+};
+```
+
+## 3. 函数与变量规范
+
+### 3.1 函数返回类型
+- **推荐显式声明函数的返回类型**：虽然 TS 具有强大的类型推导能力，但在定义公共函数、API 接口函数或复杂业务逻辑时，显式声明返回类型有助于提早发现错误并提高代码可读性。
+
+```typescript
+// ✅ 推荐做法
+function calculateTotal(price: number, quantity: number): number {
+  return price * quantity;
+}
+```
+
+### 3.2 变量类型推导
+- **让 TS 自动推导简单类型**：对于初始化时就明确赋值的简单变量，不要显式声明类型。
+
+```typescript
+// ❌ 不推荐
+const age: number = 25;
+const name: string = 'Alice';
+
+// ✅ 推荐做法 (自动推导)
+const age = 25;
+const name = 'Alice';
+```
+
+## 4. 高级类型与断言
+
+### 4.1 类型断言
+- **尽量避免使用类型断言 (`as Type` 或 `<Type>`)**。
+- 如果必须使用，说明 TS 编译器无法推断出正确的类型。请先考虑是否可以通过更好的类型定义或类型守卫来解决。
+
+### 4.2 工具类型 (Utility Types)
+- 熟练掌握并使用 TS 内置的工具类型，如 `Partial<T>`, `Required<T>`, `Readonly<T>`, `Pick<T, K>`, `Omit<T, K>`。
+- 这有助于减少重复代码，保持类型定义的 DRY 原则。
+
+```typescript
+// ✅ 推荐做法
+interface User {
+  id: string;
+  name: string;
+  email: string;
+}
+
+// 只更新部分用户信息
+type UpdateUserDto = Partial<Omit<User, 'id'>>;
+```
+
+## 5. API 请求类型规范
+
+- **统一的响应体接口**：在封装请求库时，定义统一的响应体泛型接口 (如 `ApiResponse<T>`)。
+- **为所有 API 接口定义请求和返回类型**：在 `src/api/` 目录下，每个接口必须明确入参和出参的类型。