欢迎来到Heck's Blog，专业承接拿站、企业建站、仿站、网上商城架构、门户网站搭建、空间域名注册、软件定制等项目。关注网络安全，因为专注，所以专业，懂得放弃，才能收获。有事请发邮件至i@heckjj.com，请记住本站网址：http://www.heckjj.com，多谢。
5月18
`git feat` 是指在 Git 提交（commit）信息中使用 `feat` 作为前缀，它是英文 “feature”（新功能）的缩写，用于标识本次提交新增了一个功能或特性。
这一用法源于 [Conventional Commits（约定式提交）](https://www.conventionalcommits.org/) 规范，该规范通过标准化提交信息格式，提升团队协作效率，并便于自动生成变更日志（changelog）和版本号管理。
---
常见提交类型前缀含义
- `feat`：新增功能（feature）
示例：`feat: 添加用户登录功能`
- `fix`：修复 bug
示例：`fix: 修复登录超时问题`
- `docs`：仅修改文档
示例：`docs: 更新 README 使用说明`
- `style`：代码样式调整（不影响运行）
示例：`style: 格式化代码缩进`
- `refactor`：代码重构（非新增功能、非修复 bug）
示例：`refactor: 提取用户验证逻辑为独立函数`
- `chore`：构建过程或工具依赖更新
示例：`chore: 更新 npm 依赖包`
- `test`：增加或修改测试
示例：`test: 添加登录接口单元测试`
---
提交信息结构（Conventional Commits）
标准格式为：
```
():
[body]
[footer]
```
- `type`：必须，如 `feat`、`fix` 等
- `scope`：可选，限定影响范围，如 `(auth)`、`(api)`
- `subject`：简短描述（≤50 字符）
- `body` / `footer`：可选，详细说明或关联 issue
示例完整写法：
```bash
feat(auth): 添加 Google OAuth 登录支持
- 允许用户通过 Google 账号一键登录
- 集成 OAuth2.0 流程
- 关联 JIRA-123
```
---
实践意义
- ✅ 提高可读性：团队成员快速理解提交目的
- ✅ 支持自动化：工具（如 `semantic-release`）可依据 `feat` 自动升级版本号
- ✅ 便于生成 changelog：按类型分类生成发布说明
更多规范细节可参考：[Conventional Commits 官方规范](https://www.conventionalcommits.org/)
这一用法源于 [Conventional Commits（约定式提交）](https://www.conventionalcommits.org/) 规范，该规范通过标准化提交信息格式，提升团队协作效率，并便于自动生成变更日志（changelog）和版本号管理。
---
常见提交类型前缀含义
- `feat`：新增功能（feature）
示例：`feat: 添加用户登录功能`
- `fix`：修复 bug
示例：`fix: 修复登录超时问题`
- `docs`：仅修改文档
示例：`docs: 更新 README 使用说明`
- `style`：代码样式调整（不影响运行）
示例：`style: 格式化代码缩进`
- `refactor`：代码重构（非新增功能、非修复 bug）
示例：`refactor: 提取用户验证逻辑为独立函数`
- `chore`：构建过程或工具依赖更新
示例：`chore: 更新 npm 依赖包`
- `test`：增加或修改测试
示例：`test: 添加登录接口单元测试`
---
提交信息结构（Conventional Commits）
标准格式为：
```
[body]
[footer]
```
- `type`：必须，如 `feat`、`fix` 等
- `scope`：可选，限定影响范围，如 `(auth)`、`(api)`
- `subject`：简短描述（≤50 字符）
- `body` / `footer`：可选，详细说明或关联 issue
示例完整写法：
```bash
feat(auth): 添加 Google OAuth 登录支持
- 允许用户通过 Google 账号一键登录
- 集成 OAuth2.0 流程
- 关联 JIRA-123
```
---
实践意义
- ✅ 提高可读性：团队成员快速理解提交目的
- ✅ 支持自动化：工具（如 `semantic-release`）可依据 `feat` 自动升级版本号
- ✅ 便于生成 changelog：按类型分类生成发布说明
更多规范细节可参考：[Conventional Commits 官方规范](https://www.conventionalcommits.org/)
5月18
本文档定义了团队使用 Git 的标准流程和规范，所有团队成员必须遵循。
版本：v1.0.0
最后更新：2026年
适用范围：所有项目
目录
分支管理规范
提交信息规范
工作流程规范
代码审查规范
命名规范
安全规范
工具与配置
常见场景处理
1. 分支管理规范
1.1 分支类型
主分支（Main Branches）
main / master
用途：生产环境代码
保护：✅ 必须通过 Pull Request 合并
禁止：❌ 禁止直接推送，禁止强制推送
develop
用途：开发环境代码，日常开发集成
保护：✅ 必须通过 Pull Request 合并
禁止：❌ 禁止直接推送
辅助分支（Supporting Branches）
feature/* - 功能开发分支
命名：feature/功能名称，如 feature/user-login
来源：从 develop 创建
目标：合并回 develop
生命周期：功能完成后删除
fix/* - Bug 修复分支
命名：fix/问题描述，如 fix/login-button-bug
来源：从 develop 创建
目标：合并回 develop
生命周期：修复完成后删除
hotfix/* - 紧急修复分支
命名：hotfix/紧急修复描述，如 hotfix/security-patch
来源：从 main 创建
目标：合并回 main 和 develop
生命周期：修复完成后删除
release/* - 发布准备分支
命名：release/版本号，如 release/1.0.0
来源：从 develop 创建
目标：合并回 main 和 develop
生命周期：发布完成后删除
1.2 分支命名规则
✅ 允许的命名：
使用小写字母
使用连字符 - 分隔单词
简洁但描述性
示例：feature/user-authentication、fix/payment-error
❌ 禁止的命名：
使用大写字母
使用下划线或空格
使用个人名称
使用特殊字符
示例：Feature/Login、fix_bug、zhangsan-feature
1.3 分支保护规则
main 分支保护
✅ 必须通过 Pull Request 合并
✅ 至少 1 位团队成员审查通过
✅ 必须通过所有 CI/CD 检查
✅ 禁止直接推送
✅ 禁止强制推送
✅ 禁止删除分支
develop 分支保护
✅ 必须通过 Pull Request 合并
✅ 至少 1 位团队成员审查通过
✅ 必须通过所有 CI/CD 检查
✅ 禁止直接推送
✅ 禁止强制推送
2. 提交信息规范
2.1 提交信息格式
<类型>(<范围>): <简短描述>
<详细描述（可选）>
<相关 Issue（可选）>
版本：v1.0.0
最后更新：2026年
适用范围：所有项目
目录
分支管理规范
提交信息规范
工作流程规范
代码审查规范
命名规范
安全规范
工具与配置
常见场景处理
1. 分支管理规范
1.1 分支类型
主分支（Main Branches）
main / master
用途：生产环境代码
保护：✅ 必须通过 Pull Request 合并
禁止：❌ 禁止直接推送，禁止强制推送
develop
用途：开发环境代码，日常开发集成
保护：✅ 必须通过 Pull Request 合并
禁止：❌ 禁止直接推送
辅助分支（Supporting Branches）
feature/* - 功能开发分支
命名：feature/功能名称，如 feature/user-login
来源：从 develop 创建
目标：合并回 develop
生命周期：功能完成后删除
fix/* - Bug 修复分支
命名：fix/问题描述，如 fix/login-button-bug
来源：从 develop 创建
目标：合并回 develop
生命周期：修复完成后删除
hotfix/* - 紧急修复分支
命名：hotfix/紧急修复描述，如 hotfix/security-patch
来源：从 main 创建
目标：合并回 main 和 develop
生命周期：修复完成后删除
release/* - 发布准备分支
命名：release/版本号，如 release/1.0.0
来源：从 develop 创建
目标：合并回 main 和 develop
生命周期：发布完成后删除
1.2 分支命名规则
✅ 允许的命名：
使用小写字母
使用连字符 - 分隔单词
简洁但描述性
示例：feature/user-authentication、fix/payment-error
❌ 禁止的命名：
使用大写字母
使用下划线或空格
使用个人名称
使用特殊字符
示例：Feature/Login、fix_bug、zhangsan-feature
1.3 分支保护规则
main 分支保护
✅ 必须通过 Pull Request 合并
✅ 至少 1 位团队成员审查通过
✅ 必须通过所有 CI/CD 检查
✅ 禁止直接推送
✅ 禁止强制推送
✅ 禁止删除分支
develop 分支保护
✅ 必须通过 Pull Request 合并
✅ 至少 1 位团队成员审查通过
✅ 必须通过所有 CI/CD 检查
✅ 禁止直接推送
✅ 禁止强制推送
2. 提交信息规范
2.1 提交信息格式
<类型>(<范围>): <简短描述>
<详细描述（可选）>
<相关 Issue（可选）>
5月18
一、什么是Git分支管理？
Git分支管理是指在Git版本控制系统中，通过创建和管理多个分支来组织代码开发流程，支持并行开发、代码隔离和版本控制。
简单说，就像一棵树的主干和分支，master分支是主干，feature分支是枝叶，每个分支都可以独立生长，最后再合并到主干。
其核心作用包括：
• 并行开发：多个功能可以同时开发而不相互干扰。
• 代码隔离：开发分支、测试分支、生产分支相互隔离。
• 版本管理：支持版本回退、热修复和发布管理。
• 团队协作：多人协作时减少代码冲突。
二、分支类型说明
2.1 长期存在分支（核心基础分支）
master 主分支
• 定位：生产环境分支，存放已发布的稳定、可靠版本代码。
• 核心规则：仅用于发布新版本，禁止直接修改或提交新功能。
develop 开发分支
• 定位：日常开发主分支，汇总当前所有正在推进的功能和任务。
• 核心规则：所有新功能开发、改进、优化均从该分支发起，完成后最终合并回此分支。
2.2 临时创建分支（辅助开发/发布分支，完成后删除）
feature 功能分支
• 创建来源：从 develop 分支创建，功能分支的名字，可以采用feature-*的形式命名
• 用途：单独开发某一个新功能（一个功能对应一个分支）
• 流转终点：功能实现、测试完成后，合并回 develop 分支
release 发布分支（不一定用）
• 创建来源：从 develop 分支创建
• 用途：为即将发布的版本做最终准备，仅开展测试、bug修复、文档检查等工作（不新增功能）
• 流转终点：准备完成且测试通过后，同时合并回 master 分支（作为新发布版本）和 develop 分支（同步发布前的修复内容）
hotfix 紧急修复分支
• 创建来源：从 master 分支创建
• 用途：紧急修复生产环境（master 分支对应版本）中出现的问题
• 流转终点：修复完成后，同时合并回 master 分支（更新生产版本）和 develop 分支（同步修复内容，避免后续版本复现问题）
三、业务流程图
sequenceDiagram
participant M as Master分支
participant D as Develop分支
participant F as Features功能分支
participant B as Bugfix缺陷分支
participant DT as 开发测试环境
participant PT as 生产测试环境
%% 功能开发流程（标注关键测试节点）
note over M,D: 功能开发阶段
M->>D: 从master初始化develop分支
D->>F: 基于develop创建功能分支
F->>DT: 开发完成→直接发布到开发测试环境（第一轮测试）
note over F,DT: 开发联调阶段
DT->>F: 反馈联调问题
F->>F: 在功能分支修复问题
F->>D: 修复完成→合并到develop分支
D->>DT: 合并后→再次发布到开发测试环境（第二轮验证）
DT->>F: 开发测试通过
F->>M: 功能分支合并到master分支
M->>PT: master发布到生产测试环境
%% 缺陷修复流程（标注合并develop再测试）
note over M,PT: 缺陷修复阶段
PT->>M: 反馈生产测试缺陷问题
M->>B: 基于master创建Bugfix缺陷分支
B->>B: 在Bugfix分支修复缺陷问题
B->>D: Bugfix分支→合并缺陷修复到develop
D->>DT: 合并后→发布到开发测试环境联调
DT->>D: 缺陷联调测试通过
D->>M: develop→合并缺陷修复到master
M->>PT: master再次发布到生产测试验收
M->>M: 验收通过，创建版本标签
四、常见分支策略
• master：生产环境代码，标签标记版本
• develop：开发主分支，集成功能分支
• feature：功能开发分支，从develop创建
• release：发布准备分支，从develop/master创建
• hotfix：紧急修复分支，从master创建
五、分支命名规范
• 功能分支：feature/功能名称 或 feature/issue-id-功能描述
• 发布分支：release/v1.2.0 或 release/2027-01-01
• 热修复分支：hotfix/bug-id 或 hotfix/紧急修复描述
• 开发分支：develop 或 development
六、互联网大厂Git工作流实战 devops
七、分支管理最佳实践
• 分支生命周期管理：及时删除已合并的分支
• 保护主分支：通过分支保护规则防止直接推送
• 代码审查：所有合并都需要Pull Request和审查
• 定期同步：保持分支与主分支的同步
• 标签管理：重要版本打tag标记
八、Git多分支实战和代码合并规范讲解
8.1 Git分支基本操作实战
# 查看当前分支
git branch
# 创建新分支（基于当前分支）
git branch feature/user-login
# 创建并切换到新分支
git checkout -b feature/user-login
# 基于指定分支创建新分支
git checkout -b feature/payment develop
# 查看所有分支（包括远程）
git branch -a
8.2 分支工作流完整演练
功能开发工作流
# 1. 从develop分支创建功能分支
git checkout develop
git pull origin develop
git checkout -b feature/user-registration
# 2. 开发功能并提交
# ... 开发代码 ...
git add .
git commit -m "feat: 增加用户注册功能"
# 3. 推送分支到远程
git push origin feature/user-registration
# 4. 创建Pull Request/Merge Request
# 在GitHub/GitLab上创建PR
# 5. 同步最新代码
git checkout develop
git pull origin develop
git checkout feature/user-registration
# 6. 解决可能的冲突
# ... 解决冲突 ...
# 7. 推送更新后的分支
git push origin feature/user-registration --force-with-lease
紧急修复工作流
# 1. 从master创建热修复分支
git checkout master
git pull origin master
git checkout -b hotfix/critical-bug-fix
# 2. 修复bug
# ... 修复代码 ...
git add .
git commit -m "fix: 解决严重的授权问题"
# 3. 同时合并到master和develop
git checkout master
git merge hotfix/critical-bug-fix
git push origin master
git checkout develop
#将热修复代码合并到develop分支，同步修复逻辑到开发分支。
git merge hotfix/critical-bug-fix
git push origin develop
# 4. 删除热修复分支
git branch -d hotfix/critical-bug-fix
代码合并规范说明
提交信息规范
# 格式：type(scope): description
git commit -m "feat(授权): 增加JWT授权验证"
# 常用type：
# feat: 新功能
# fix: 修复bug
# docs: 文档更新
# style: 代码格式调整
# refactor: 代码重构
# test: 测试相关
分支命名规范
• 功能分支：feature/功能名称 或 feature/issue-123-user-login
• 修复分支：fix/bug描述 或 fix/issue-456-data-validation
• 发布分支：release/v1.2.0
• 热修复：hotfix/紧急修复描述
合并请求规范
• 标题清晰描述变更内容
• 详细描述变更原因和影响
• 关联相关issue或需求
• 提供测试说明和验证步骤
Git分支管理是指在Git版本控制系统中，通过创建和管理多个分支来组织代码开发流程，支持并行开发、代码隔离和版本控制。
简单说，就像一棵树的主干和分支，master分支是主干，feature分支是枝叶，每个分支都可以独立生长，最后再合并到主干。
其核心作用包括：
• 并行开发：多个功能可以同时开发而不相互干扰。
• 代码隔离：开发分支、测试分支、生产分支相互隔离。
• 版本管理：支持版本回退、热修复和发布管理。
• 团队协作：多人协作时减少代码冲突。
二、分支类型说明
2.1 长期存在分支（核心基础分支）
master 主分支
• 定位：生产环境分支，存放已发布的稳定、可靠版本代码。
• 核心规则：仅用于发布新版本，禁止直接修改或提交新功能。
develop 开发分支
• 定位：日常开发主分支，汇总当前所有正在推进的功能和任务。
• 核心规则：所有新功能开发、改进、优化均从该分支发起，完成后最终合并回此分支。
2.2 临时创建分支（辅助开发/发布分支，完成后删除）
feature 功能分支
• 创建来源：从 develop 分支创建，功能分支的名字，可以采用feature-*的形式命名
• 用途：单独开发某一个新功能（一个功能对应一个分支）
• 流转终点：功能实现、测试完成后，合并回 develop 分支
release 发布分支（不一定用）
• 创建来源：从 develop 分支创建
• 用途：为即将发布的版本做最终准备，仅开展测试、bug修复、文档检查等工作（不新增功能）
• 流转终点：准备完成且测试通过后，同时合并回 master 分支（作为新发布版本）和 develop 分支（同步发布前的修复内容）
hotfix 紧急修复分支
• 创建来源：从 master 分支创建
• 用途：紧急修复生产环境（master 分支对应版本）中出现的问题
• 流转终点：修复完成后，同时合并回 master 分支（更新生产版本）和 develop 分支（同步修复内容，避免后续版本复现问题）
三、业务流程图
sequenceDiagram
participant M as Master分支
participant D as Develop分支
participant F as Features功能分支
participant B as Bugfix缺陷分支
participant DT as 开发测试环境
participant PT as 生产测试环境
%% 功能开发流程（标注关键测试节点）
note over M,D: 功能开发阶段
M->>D: 从master初始化develop分支
D->>F: 基于develop创建功能分支
F->>DT: 开发完成→直接发布到开发测试环境（第一轮测试）
note over F,DT: 开发联调阶段
DT->>F: 反馈联调问题
F->>F: 在功能分支修复问题
F->>D: 修复完成→合并到develop分支
D->>DT: 合并后→再次发布到开发测试环境（第二轮验证）
DT->>F: 开发测试通过
F->>M: 功能分支合并到master分支
M->>PT: master发布到生产测试环境
%% 缺陷修复流程（标注合并develop再测试）
note over M,PT: 缺陷修复阶段
PT->>M: 反馈生产测试缺陷问题
M->>B: 基于master创建Bugfix缺陷分支
B->>B: 在Bugfix分支修复缺陷问题
B->>D: Bugfix分支→合并缺陷修复到develop
D->>DT: 合并后→发布到开发测试环境联调
DT->>D: 缺陷联调测试通过
D->>M: develop→合并缺陷修复到master
M->>PT: master再次发布到生产测试验收
M->>M: 验收通过，创建版本标签
四、常见分支策略
• master：生产环境代码，标签标记版本
• develop：开发主分支，集成功能分支
• feature：功能开发分支，从develop创建
• release：发布准备分支，从develop/master创建
• hotfix：紧急修复分支，从master创建
五、分支命名规范
• 功能分支：feature/功能名称 或 feature/issue-id-功能描述
• 发布分支：release/v1.2.0 或 release/2027-01-01
• 热修复分支：hotfix/bug-id 或 hotfix/紧急修复描述
• 开发分支：develop 或 development
六、互联网大厂Git工作流实战 devops
七、分支管理最佳实践
• 分支生命周期管理：及时删除已合并的分支
• 保护主分支：通过分支保护规则防止直接推送
• 代码审查：所有合并都需要Pull Request和审查
• 定期同步：保持分支与主分支的同步
• 标签管理：重要版本打tag标记
八、Git多分支实战和代码合并规范讲解
8.1 Git分支基本操作实战
# 查看当前分支
git branch
# 创建新分支（基于当前分支）
git branch feature/user-login
# 创建并切换到新分支
git checkout -b feature/user-login
# 基于指定分支创建新分支
git checkout -b feature/payment develop
# 查看所有分支（包括远程）
git branch -a
8.2 分支工作流完整演练
功能开发工作流
# 1. 从develop分支创建功能分支
git checkout develop
git pull origin develop
git checkout -b feature/user-registration
# 2. 开发功能并提交
# ... 开发代码 ...
git add .
git commit -m "feat: 增加用户注册功能"
# 3. 推送分支到远程
git push origin feature/user-registration
# 4. 创建Pull Request/Merge Request
# 在GitHub/GitLab上创建PR
# 5. 同步最新代码
git checkout develop
git pull origin develop
git checkout feature/user-registration
# 6. 解决可能的冲突
# ... 解决冲突 ...
# 7. 推送更新后的分支
git push origin feature/user-registration --force-with-lease
紧急修复工作流
# 1. 从master创建热修复分支
git checkout master
git pull origin master
git checkout -b hotfix/critical-bug-fix
# 2. 修复bug
# ... 修复代码 ...
git add .
git commit -m "fix: 解决严重的授权问题"
# 3. 同时合并到master和develop
git checkout master
git merge hotfix/critical-bug-fix
git push origin master
git checkout develop
#将热修复代码合并到develop分支，同步修复逻辑到开发分支。
git merge hotfix/critical-bug-fix
git push origin develop
# 4. 删除热修复分支
git branch -d hotfix/critical-bug-fix
代码合并规范说明
提交信息规范
# 格式：type(scope): description
git commit -m "feat(授权): 增加JWT授权验证"
# 常用type：
# feat: 新功能
# fix: 修复bug
# docs: 文档更新
# style: 代码格式调整
# refactor: 代码重构
# test: 测试相关
分支命名规范
• 功能分支：feature/功能名称 或 feature/issue-123-user-login
• 修复分支：fix/bug描述 或 fix/issue-456-data-validation
• 发布分支：release/v1.2.0
• 热修复：hotfix/紧急修复描述
合并请求规范
• 标题清晰描述变更内容
• 详细描述变更原因和影响
• 关联相关issue或需求
• 提供测试说明和验证步骤
一、什么是Git分支管理？
Git分支管理是指在Git版本控制系统中，通过创建和管理多个分支来组织代码开发流程，支持并行开发、代码隔离和版本控制。
简单说，就像一棵树的主干和分支，master分支是主干，feature分支是枝叶，每个分支都可以独立生长，最后再合并到主干。
其核心作用包括：
- 并行开发：多个功能可以同时开发而不相互干扰。
- 代码隔离：开发分支、测试分支、生产分支相互隔离。
- 版本管理：支持版本回退、热修复和发布管理。
- 团队协作：多人协作时减少代码冲突。
二、分支类型说明
2.1 长期存在分支（核心基础分支）
master 主分支
- 定位：生产环境分支，存放已发布的稳定、可靠版本代码。
- 核心规则：仅用于发布新版本，禁止直接修改或提交新功能。
develop 开发分支
- 定位：日常开发主分支，汇总当前所有正在推进的功能和任务。
- 核心规则：所有新功能开发、改进、优化均从该分支发起，完成后最终合并回此分支。
2.2 临时创建分支（辅助开发/发布分支，完成后删除）
feature 功能分支
- 创建来源：从 develop 分支创建，功能分支的名字，可以采用feature-*的形式命名
- 用途：单独开发某一个新功能（一个功能对应一个分支）
- 流转终点：功能实现、测试完成后，合并回 develop 分支
release 发布分支（不一定用）
- 创建来源：从 develop 分支创建
- 用途：为即将发布的版本做最终准备，仅开展测试、bug修复、文档检查等工作（不新增功能）
- 流转终点：准备完成且测试通过后，同时合并回 master 分支（作为新发布版本）和 develop 分支（同步发布前的修复内容）
hotfix 紧急修复分支
- 创建来源：从 master 分支创建
- 用途：紧急修复生产环境（master 分支对应版本）中出现的问题
- 流转终点：修复完成后，同时合并回 master 分支（更新生产版本）和 develop 分支（同步修复内容，避免后续版本复现问题）
三、业务流程图
sequenceDiagram participant M as Master分支 participant D as Develop分支 participant F as Features功能分支 participant B as Bugfix缺陷分支 participant DT as 开发测试环境 participant PT as 生产测试环境 %% 功能开发流程（标注关键测试节点） note over M,D: 功能开发阶段 M->>D: 从master初始化develop分支 D->>F: 基于develop创建功能分支 F->>DT: 开发完成→直接发布到开发测试环境（第一轮测试） note over F,DT: 开发联调阶段 DT->>F: 反馈联调问题 F->>F: 在功能分支修复问题 F->>D: 修复完成→合并到develop分支 D->>DT: 合并后→再次发布到开发测试环境（第二轮验证） DT->>F: 开发测试通过 F->>M: 功能分支合并到master分支 M->>PT: master发布到生产测试环境 %% 缺陷修复流程（标注合并develop再测试） note over M,PT: 缺陷修复阶段 PT->>M: 反馈生产测试缺陷问题 M->>B: 基于master创建Bugfix缺陷分支 B->>B: 在Bugfix分支修复缺陷问题 B->>D: Bugfix分支→合并缺陷修复到develop D->>DT: 合并后→发布到开发测试环境联调 DT->>D: 缺陷联调测试通过 D->>M: develop→合并缺陷修复到master M->>PT: master再次发布到生产测试验收 M->>M: 验收通过，创建版本标签
四、常见分支策略
- master：生产环境代码，标签标记版本
- develop：开发主分支，集成功能分支
- feature：功能开发分支，从develop创建
- release：发布准备分支，从develop/master创建
- hotfix：紧急修复分支，从master创建
五、分支命名规范
- 功能分支：feature/功能名称 或 feature/issue-id-功能描述
- 发布分支：release/v1.2.0 或 release/2027-01-01
- 热修复分支：hotfix/bug-id 或 hotfix/紧急修复描述
- 开发分支：develop 或 development
六、互联网大厂Git工作流实战 devops
七、分支管理最佳实践
- 分支生命周期管理：及时删除已合并的分支
- 保护主分支：通过分支保护规则防止直接推送
- 代码审查：所有合并都需要Pull Request和审查
- 定期同步：保持分支与主分支的同步
- 标签管理：重要版本打tag标记
八、Git多分支实战和代码合并规范讲解
8.1 Git分支基本操作实战
# 查看当前分支 git branch # 创建新分支（基于当前分支） git branch feature/user-login # 创建并切换到新分支 git checkout -b feature/user-login # 基于指定分支创建新分支 git checkout -b feature/payment develop # 查看所有分支（包括远程） git branch -a
8.2 分支工作流完整演练
功能开发工作流
# 1. 从develop分支创建功能分支 git checkout develop git pull origin develop git checkout -b feature/user-registration # 2. 开发功能并提交 # ... 开发代码 ... git add . git commit -m "feat: 增加用户注册功能" # 3. 推送分支到远程 git push origin feature/user-registration # 4. 创建Pull Request/Merge Request # 在GitHub/GitLab上创建PR # 5. 同步最新代码 git checkout develop git pull origin develop git checkout feature/user-registration # 6. 解决可能的冲突 # ... 解决冲突 ... # 7. 推送更新后的分支 git push origin feature/user-registration --force-with-lease
紧急修复工作流
# 1. 从master创建热修复分支 git checkout master git pull origin master git checkout -b hotfix/critical-bug-fix # 2. 修复bug # ... 修复代码 ... git add . git commit -m "fix: 解决严重的授权问题" # 3. 同时合并到master和develop git checkout master git merge hotfix/critical-bug-fix git push origin master git checkout develop #将热修复代码合并到develop分支，同步修复逻辑到开发分支。 git merge hotfix/critical-bug-fix git push origin develop # 4. 删除热修复分支 git branch -d hotfix/critical-bug-fix
代码合并规范说明
提交信息规范
# 格式：type(scope): description git commit -m "feat(授权): 增加JWT授权验证" # 常用type： # feat: 新功能 # fix: 修复bug # docs: 文档更新 # style: 代码格式调整 # refactor: 代码重构 # test: 测试相关
分支命名规范
- 功能分支：feature/功能名称 或 feature/issue-123-user-login
- 修复分支：fix/bug描述 或 fix/issue-456-data-validation
- 发布分支：release/v1.2.0
- 热修复：hotfix/紧急修复描述
合并请求规范
- 标题清晰描述变更内容
- 详细描述变更原因和影响
- 关联相关issue或需求
- 提供测试说明和验证步骤
4月9
随着 Java 生态的演进，我们将核心项目从 JDK 8 迁移至 JDK 21。然而，在升级过程中，我们遇到了一个令人费解的现象：原本在 JDK 8 上运行正常的第三方接口调用，在 JDK 21 上却频繁抛出 SSLHandshakeException: Received fatal alert: handshake_failure。本文将详细复盘这次排查过程，揭示 JDK 21 在 SSL/TLS 握手层面的底层变化，并提供终极解决方案。
一、 故障现象：版本升级后的“断连”
在将开发环境切换至 JDK 21 后，我们的应用在调用特定政府网站接口（https://www.xxx.gov.cn）时发生了故障。
错误日志：
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
诡异现象：
JDK 8： 运行完美，无任何报错。
JDK 21： 死活连不上，且不报证书错误（CertificateException），直接握手失败。
浏览器/Postman： 可以正常访问。
这种“代码没变，环境变了”的差异，直接指向了 JDK 版本间的底层安全策略差异。
二、 排查之路：层层递进的“破案”过程
为了定位问题，我们开启 -Djavax.net.debug=ssl:handshake 调试模式，通过分析握手日志，我们经历了三个阶段的认知升级。
第一阶段：误判为“弱加密算法” —— 方案失效
直觉： JDK 21 更安全，默认禁用了弱算法。我们猜测是服务器使用了 MD5 或 1024 位密钥。
行动： 修改 java.security 文件，删除 jdk.tls.disabledAlgorithms 中的限制，甚至加上了 ECDH（误以为是禁用了 ECDH 导致的）。
结果： 无效。 即使放宽了所有限制，握手依然失败。这说明问题不在“禁用列表”，而在“协商过程”。
第二阶段：聚焦“椭圆曲线” —— 关键线索
在仔细比对 ClientHello（客户端发起）和 ServerHello（服务器回复）的日志时，我们发现了异常。
在服务器的 ECDHServerKeyExchange 消息中，出现了如下关键字段：
"ECDH ServerKeyExchange": {
"parameters": {
"named group": "x448" // 服务器强制要求使用 x448 曲线
}
}
一、 故障现象：版本升级后的“断连”
在将开发环境切换至 JDK 21 后，我们的应用在调用特定政府网站接口（https://www.xxx.gov.cn）时发生了故障。
错误日志：
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
诡异现象：
JDK 8： 运行完美，无任何报错。
JDK 21： 死活连不上，且不报证书错误（CertificateException），直接握手失败。
浏览器/Postman： 可以正常访问。
这种“代码没变，环境变了”的差异，直接指向了 JDK 版本间的底层安全策略差异。
二、 排查之路：层层递进的“破案”过程
为了定位问题，我们开启 -Djavax.net.debug=ssl:handshake 调试模式，通过分析握手日志，我们经历了三个阶段的认知升级。
第一阶段：误判为“弱加密算法” —— 方案失效
直觉： JDK 21 更安全，默认禁用了弱算法。我们猜测是服务器使用了 MD5 或 1024 位密钥。
行动： 修改 java.security 文件，删除 jdk.tls.disabledAlgorithms 中的限制，甚至加上了 ECDH（误以为是禁用了 ECDH 导致的）。
结果： 无效。 即使放宽了所有限制，握手依然失败。这说明问题不在“禁用列表”，而在“协商过程”。
第二阶段：聚焦“椭圆曲线” —— 关键线索
在仔细比对 ClientHello（客户端发起）和 ServerHello（服务器回复）的日志时，我们发现了异常。
在服务器的 ECDHServerKeyExchange 消息中，出现了如下关键字段：
"ECDH ServerKeyExchange": {
"parameters": {
"named group": "x448" // 服务器强制要求使用 x448 曲线
}
}
2月5
限时活动，免费白嫖Nano Banana Pro、Gemini3.0、GPT5.2等最新模型，在问AI出的活动，估计也是为了推广，白嫖付费ai，基本无限用gemini3.0pro，完全无限使用nanobanana和即梦4.0绘图。
点此跳转注册
邀请链接注册后，你我都可以获得99999点数，用来Ai文本对话或Ai绘图，你有体验无限时卡。
点此跳转注册
邀请链接注册后，你我都可以获得99999点数，用来Ai文本对话或Ai绘图，你有体验无限时卡。
2月2
编写干净、易于理解且可维护的代码是每位开发者必须掌握的技能。我们将探讨提高代码质量的最重要原则，并为每个原则提供代码示例。
如何命名变量（以及其他事物）
我们不用内存地址而使用名称的原因是：名称更容易记忆。更重要的是，它们能提供更多关于变量的信息，以便其他人理解其意义。
找到一个好的名字可能需要一些时间，但这将在未来为你和你的团队节省更多时间。而且我确信大多数读者都遇到过这种情况：几个月后再次访问自己的代码时，很难理解之前做了什么。
如何创建有意义的名字
不要用注释来解释变量的用途。如果一个名字需要注释，那么你应该花时间重命名那个变量，而不是写注释。
差：
var d; // elapsed time in days
我见过这种代码无数次。人们普遍认为应该用注释来隐藏代码的混乱，但这是一种常见的误解。除非有充分理由，否则不要使用 x、y、a 或 b 等字母作为变量名（循环变量除外）。
好：
var elapsedTimeInDays;
var daysSinceCreation;
var daysSinceModification;
这些名称要好得多。它们告诉你被测量的内容以及该测量的单位。
避免错误信息
注意那些有特定含义的词语。除非其类型确实是 List，否则不要将一组账户称为 accountList。这个词有特定的含义，可能会导致错误的结论。
即使类型是列表，accounts 也是一个更简单、更好的名称。
差：
var accountList = [];
好：
var accounts = [];
避免噪音词
噪声词是指那些不提供任何关于变量额外信息的词。它们是冗余的，应该被删除。
一些常见的噪声词有：
The (prefix)
Info
Data
Variable
Object
Manager
如果你的类名是 UserInfo，你只需去掉 Info，直接用 User。将类名用 BookData 代替 Book 是毋庸置疑的，因为类本来就是为了存储数据而存在的。
使用发音友好的名称
如果你不会读一个名字，讨论它时就会显得很愚蠢。
差：
const yyyymmdstr = moment().format("YYYY/MM/DD");
好：
const currentDate = moment().format("YYYY/MM/DD");
使用可搜索的名称
避免在代码中使用魔法数字。选择可搜索的、命名的常量。不要为常量使用单个字母的名称，因为它们可能出现在很多地方，因此不易搜索。
差：
if (student.classes.length < 7) {
// Do something
}
好：
if (student.classes.length < MAX_CLASSES_PER_STUDENT) {
// Do something
}
这样更好，因为 MAX_CLASSES_PER_STUDENT 可以在代码的许多地方使用。如果将来需要将其改为 6，我们只需更改常量即可。
糟糕的例子会在读者脑海中产生疑问，比如 7 的重要性是什么？
你也应该使用你语言的常量命名和声明约定，例如 Java 中的 private static final 或 JavaScript 中的 const。
如何命名变量（以及其他事物）
我们不用内存地址而使用名称的原因是：名称更容易记忆。更重要的是，它们能提供更多关于变量的信息，以便其他人理解其意义。
找到一个好的名字可能需要一些时间，但这将在未来为你和你的团队节省更多时间。而且我确信大多数读者都遇到过这种情况：几个月后再次访问自己的代码时，很难理解之前做了什么。
如何创建有意义的名字
不要用注释来解释变量的用途。如果一个名字需要注释，那么你应该花时间重命名那个变量，而不是写注释。
差：
var d; // elapsed time in days
我见过这种代码无数次。人们普遍认为应该用注释来隐藏代码的混乱，但这是一种常见的误解。除非有充分理由，否则不要使用 x、y、a 或 b 等字母作为变量名（循环变量除外）。
好：
var elapsedTimeInDays;
var daysSinceCreation;
var daysSinceModification;
这些名称要好得多。它们告诉你被测量的内容以及该测量的单位。
避免错误信息
注意那些有特定含义的词语。除非其类型确实是 List，否则不要将一组账户称为 accountList。这个词有特定的含义，可能会导致错误的结论。
即使类型是列表，accounts 也是一个更简单、更好的名称。
差：
var accountList = [];
好：
var accounts = [];
避免噪音词
噪声词是指那些不提供任何关于变量额外信息的词。它们是冗余的，应该被删除。
一些常见的噪声词有：
The (prefix)
Info
Data
Variable
Object
Manager
如果你的类名是 UserInfo，你只需去掉 Info，直接用 User。将类名用 BookData 代替 Book 是毋庸置疑的，因为类本来就是为了存储数据而存在的。
使用发音友好的名称
如果你不会读一个名字，讨论它时就会显得很愚蠢。
差：
const yyyymmdstr = moment().format("YYYY/MM/DD");
好：
const currentDate = moment().format("YYYY/MM/DD");
使用可搜索的名称
避免在代码中使用魔法数字。选择可搜索的、命名的常量。不要为常量使用单个字母的名称，因为它们可能出现在很多地方，因此不易搜索。
差：
if (student.classes.length < 7) {
// Do something
}
好：
if (student.classes.length < MAX_CLASSES_PER_STUDENT) {
// Do something
}
这样更好，因为 MAX_CLASSES_PER_STUDENT 可以在代码的许多地方使用。如果将来需要将其改为 6，我们只需更改常量即可。
糟糕的例子会在读者脑海中产生疑问，比如 7 的重要性是什么？
你也应该使用你语言的常量命名和声明约定，例如 Java 中的 private static final 或 JavaScript 中的 const。
1月29
Sublime Text V4200及以上版本激活注册方法另请参阅：
https://www.heckjj.com/post/678/
问题描述
2025.01.20 Sublime Text更新了最新版本V4192，本文介绍该版本的激活注册方法
本文激活注册方法同样适用于V4192及以下版本(已实测版本：V4180~V4192)
激活过程无需使用第三方软件
下载地址
官方网址：https://www.sublimetext.com
更新日志：https://www.sublimetext.com/download
下载地址(V4200 64位)：https://download.sublimetext.com/sublime_text_build_4192_x64_setup.exe
未激活表现显示为unregisted
激活方法
找到Sublime Text安装路径
右键快捷方式→打开文件所在的位置
默认安装路径：C:\Program Files\Sublime Text
找到sublime_text.exe，拷贝一份副本，使用Sublime Text打开副本文件
也可以使用其它能够以十六进制打开exe文件的编辑软件
另外推荐一个基于浏览器的在线十六进制编辑工具：https://hexed.it/
使用快捷键Ctrl + H打开搜索替换功能
查找以下十六进制字段
8079 0500 0f94 c2
替换为
c641 0501 b200 90
替换完成后使用快捷键Ctrl + S保存并关闭
移除原sublime_text.exe文件(或改为其它名称备份)，然后将编辑后的副本文件名称修改为sublime_text.exe
激活后表现
https://www.heckjj.com/post/678/
问题描述
2025.01.20 Sublime Text更新了最新版本V4192，本文介绍该版本的激活注册方法
本文激活注册方法同样适用于V4192及以下版本(已实测版本：V4180~V4192)
激活过程无需使用第三方软件
下载地址
官方网址：https://www.sublimetext.com
更新日志：https://www.sublimetext.com/download
下载地址(V4200 64位)：https://download.sublimetext.com/sublime_text_build_4192_x64_setup.exe
未激活表现显示为unregisted
激活方法
找到Sublime Text安装路径
右键快捷方式→打开文件所在的位置
默认安装路径：C:\Program Files\Sublime Text
找到sublime_text.exe，拷贝一份副本，使用Sublime Text打开副本文件
也可以使用其它能够以十六进制打开exe文件的编辑软件
另外推荐一个基于浏览器的在线十六进制编辑工具：https://hexed.it/
使用快捷键Ctrl + H打开搜索替换功能
查找以下十六进制字段
8079 0500 0f94 c2
替换为
c641 0501 b200 90
替换完成后使用快捷键Ctrl + S保存并关闭
移除原sublime_text.exe文件(或改为其它名称备份)，然后将编辑后的副本文件名称修改为sublime_text.exe
激活后表现
1月28
Sublime Text V4192及以下版本激活注册方法另请参阅：
https://www.heckjj.com/post/679/
问题描述
2025.05.21 Sublime Text更新了最新版本V4200，本文介绍该版本的激活注册方法
激活过程无需使用第三方软件
下载地址
官方网址：https://www.sublimetext.com
更新日志：https://www.sublimetext.com/download
下载地址(V4200 64位)：https://download.sublimetext.com/sublime_text_build_4200_x64_setup.exe
未激活表现显示为unregisted
激活方法
1、找到Sublime Text安装路径
右键快捷方式→打开文件所在的位置
默认安装路径：C:\Program Files\Sublime Text
2、找到sublime_text.exe，拷贝一份副本，使用Sublime Text打开副本文件
也可以使用其它能够以十六进制打开exe文件的编辑软件
另外推荐一个基于浏览器的在线十六进制编辑工具：https://hexed.it/
使用快捷键Ctrl + H打开搜索替换功能
查找以下十六进制字段
0fb6 5105 83f2 01
替换为(二选其一即可)
c641 0501 b200 90
或
c641 0501 4885 c0
替换完成后使用快捷键Ctrl + S保存并关闭
移除原sublime_text.exe文件(建议改为其它名称留作备份)，然后将编辑后的副本文件名称修改为sublime_text.exe
激活后表现为无unregisted
https://www.heckjj.com/post/679/
问题描述
2025.05.21 Sublime Text更新了最新版本V4200，本文介绍该版本的激活注册方法
激活过程无需使用第三方软件
下载地址
官方网址：https://www.sublimetext.com
更新日志：https://www.sublimetext.com/download
下载地址(V4200 64位)：https://download.sublimetext.com/sublime_text_build_4200_x64_setup.exe
未激活表现显示为unregisted
激活方法
1、找到Sublime Text安装路径
右键快捷方式→打开文件所在的位置
默认安装路径：C:\Program Files\Sublime Text
2、找到sublime_text.exe，拷贝一份副本，使用Sublime Text打开副本文件
也可以使用其它能够以十六进制打开exe文件的编辑软件
另外推荐一个基于浏览器的在线十六进制编辑工具：https://hexed.it/
使用快捷键Ctrl + H打开搜索替换功能
查找以下十六进制字段
0fb6 5105 83f2 01
替换为(二选其一即可)
c641 0501 b200 90
或
c641 0501 4885 c0
替换完成后使用快捷键Ctrl + S保存并关闭
移除原sublime_text.exe文件(建议改为其它名称留作备份)，然后将编辑后的副本文件名称修改为sublime_text.exe
激活后表现为无unregisted
1月21
由于售后服务条款：已激活windows系统或Ofice的主机，不支持7天无理由退换货。由于windows系统联网时自动激活，请您确认需求后再激活使用。
在Windows 11安装或首次设置过程中跳过联网步骤，可通过命令提示符输入特定指令实现。核心方法是：在联网界面按 Shift + F10（笔记本需加 Fn）打开命令提示符，输入 oobe\bypassnro 后回车，重启后选择“我没有Internet连接”选项即可。以下是详细步骤：
操作步骤（通用方法）
此方法适用于所有Windows 11版本（24H2及更早），成功率最高：
进入联网界面：在系统安装或首次开机设置时，到达“连接网络”页面（需输入Wi-Fi或网线连接）。
打开命令提示符：
台式机：直接按 Shift + F10。
笔记本：按 Fn + Shift + F10（部分机型需组合键）。
输入跳过指令：
在弹出窗口中输入：oobe\bypassnro（或 oobe\bypassnro.cmd），按回车。
或者先cd oobe再输入bypassnro.cmd回车
系统自动重启（约1-2分钟）。
选择离线选项：
重启后返回联网界面，点击底部 “我没有Internet连接”。
后续按提示设置本地账户（无需微软账号）。
注意事项
网络断开建议：若在虚拟机或笔记本操作，提前断开Wi-Fi/网线可提高成功率（非必须）。
命令无效处理：若输入后未重启，检查拼写（如 bypassnro 非 BYPASSNRO），或改用任务管理器结束 OOBE Network Connection Flow 进程。
后续影响：跳过联网后部分功能受限（如OneDrive同步），但基础使用无碍；进入桌面后可重新联网。
在Windows 11安装或首次设置过程中跳过联网步骤，可通过命令提示符输入特定指令实现。核心方法是：在联网界面按 Shift + F10（笔记本需加 Fn）打开命令提示符，输入 oobe\bypassnro 后回车，重启后选择“我没有Internet连接”选项即可。以下是详细步骤：
操作步骤（通用方法）
此方法适用于所有Windows 11版本（24H2及更早），成功率最高：
进入联网界面：在系统安装或首次开机设置时，到达“连接网络”页面（需输入Wi-Fi或网线连接）。
打开命令提示符：
台式机：直接按 Shift + F10。
笔记本：按 Fn + Shift + F10（部分机型需组合键）。
输入跳过指令：
在弹出窗口中输入：oobe\bypassnro（或 oobe\bypassnro.cmd），按回车。
或者先cd oobe再输入bypassnro.cmd回车
系统自动重启（约1-2分钟）。
选择离线选项：
重启后返回联网界面，点击底部 “我没有Internet连接”。
后续按提示设置本地账户（无需微软账号）。
注意事项
网络断开建议：若在虚拟机或笔记本操作，提前断开Wi-Fi/网线可提高成功率（非必须）。
命令无效处理：若输入后未重启，检查拼写（如 bypassnro 非 BYPASSNRO），或改用任务管理器结束 OOBE Network Connection Flow 进程。
后续影响：跳过联网后部分功能受限（如OneDrive同步），但基础使用无碍；进入桌面后可重新联网。
1月19
win11家庭版升级到专业版/企业版教程，专业版/企业版回退到家庭版也是一样的
准备工作
资源都是网上获取的，网友分享出来的，不一定都有效，作者试的时候第一个专业版就可以使用。
win11专业版序烈号：
D9W3G-NR2D7-6W3RK-WDD4J-7FR9G
Y7DJH-BN6WF-BB3RV-82F8F-R3KTY
Y4N7X-CF46G-92G6X-PW86V-VT9TT
RWQ2G-NXBQJ-JRT27-WX36H-JQKTT
H7HNM-BWTTC-4M99X-KM3Y3-B98XG
RHNCY-6QJWF-WPHP7-2FP87-4C2KG
win11家庭版序烈号：
MNBKY-RCQKQ-HHC9Q-M99RP-D68K3
NT7K-GCD4D-WYVCH-W6CRX-Y7TVD
7WVY4-3N6D4-WRQBV-286XJ-7FQ3Q
PNGPM-B8MVX-VV7MH-MJ9M7-MBGVD
TFFXW-N6BG8-6WTBC-3Q4GY-CWD3Q
D9YRN-B6QMK-XF7BY-6DM99-RM33Q
win11教育版序烈号：
RNXJ9-3R383-8HDD2-44K63-Y4G4V
768RN-FVXXG-7DTYF-XGVJ3-XHJWB
JFMNH-FY6TV-T2JCW-6R6P3-T6PJB
V279K-24N46-KM9BG-VVMT8-JFG4V
XGVPP-NMH47-7TTHJ-W3FW7-8HV2C
win11企业版序烈号：
WGGHN-J84D6-QYCPR-T7PJ7-X766F
3KHY7-WNT83-DGQKR-F7HPR-844BM
7HNRX-D7KGG-3K4RQ-4WPJ4-YTDFH
PVMJN-6DFY6-9CCP6-7BKTT-D3WVR
TX9XD-98N7V-6WMQ6-BX7FG-H8Q99
PPBK3-M92CH-MRR9X-34Y9P-7CH2F
可以用这两个序烈号试试看
J8WVF-9X3GM-4WVYC-VDHQG-42CXT
7Y64F-88DCY-Y6WTC-H33D2-64QHF
开始
1、打开系统设置，并选择激活
2、选择更改产品秘钥；
备注：因为本人已经激活了，这里只是演示，真实操作方法也是这样；
3、在对话匡中输入你想要激活的windows 11版本
我用的是D9W3G-NR2D7-6W3RK-WDD4J-7FR9G；
完成后最好重启一下电脑；
准备工作
资源都是网上获取的，网友分享出来的，不一定都有效，作者试的时候第一个专业版就可以使用。
win11专业版序烈号：
D9W3G-NR2D7-6W3RK-WDD4J-7FR9G
Y7DJH-BN6WF-BB3RV-82F8F-R3KTY
Y4N7X-CF46G-92G6X-PW86V-VT9TT
RWQ2G-NXBQJ-JRT27-WX36H-JQKTT
H7HNM-BWTTC-4M99X-KM3Y3-B98XG
RHNCY-6QJWF-WPHP7-2FP87-4C2KG
win11家庭版序烈号：
MNBKY-RCQKQ-HHC9Q-M99RP-D68K3
NT7K-GCD4D-WYVCH-W6CRX-Y7TVD
7WVY4-3N6D4-WRQBV-286XJ-7FQ3Q
PNGPM-B8MVX-VV7MH-MJ9M7-MBGVD
TFFXW-N6BG8-6WTBC-3Q4GY-CWD3Q
D9YRN-B6QMK-XF7BY-6DM99-RM33Q
win11教育版序烈号：
RNXJ9-3R383-8HDD2-44K63-Y4G4V
768RN-FVXXG-7DTYF-XGVJ3-XHJWB
JFMNH-FY6TV-T2JCW-6R6P3-T6PJB
V279K-24N46-KM9BG-VVMT8-JFG4V
XGVPP-NMH47-7TTHJ-W3FW7-8HV2C
win11企业版序烈号：
WGGHN-J84D6-QYCPR-T7PJ7-X766F
3KHY7-WNT83-DGQKR-F7HPR-844BM
7HNRX-D7KGG-3K4RQ-4WPJ4-YTDFH
PVMJN-6DFY6-9CCP6-7BKTT-D3WVR
TX9XD-98N7V-6WMQ6-BX7FG-H8Q99
PPBK3-M92CH-MRR9X-34Y9P-7CH2F
可以用这两个序烈号试试看
J8WVF-9X3GM-4WVYC-VDHQG-42CXT
7Y64F-88DCY-Y6WTC-H33D2-64QHF
开始
1、打开系统设置，并选择激活
2、选择更改产品秘钥；
备注：因为本人已经激活了，这里只是演示，真实操作方法也是这样；
3、在对话匡中输入你想要激活的windows 11版本
我用的是D9W3G-NR2D7-6W3RK-WDD4J-7FR9G；
完成后最好重启一下电脑；
