当前位置： 首页 > news >正文

彻底搞懂checkout：Git命令与GitHub Actions的区别与实战

news 2026/8/31 20:51:27

在日常开发中，checkout这个词几乎每天都会出现，但它经常让新手甚至有一定经验的开发者感到困惑：在本地终端里敲git checkout是在切换分支、恢复文件；在 GitHub Actions 工作流里写actions/checkout@v4又是在拉取仓库代码。明明是同一个单词，在不同场景下表达的含义却完全不同，导致很多人配置 CI 时一头雾水。

本文就围绕actions/checkout和git checkout这两个核心概念展开，先理清它们的本质区别，再分别讲解详细用法，最后用一个完整的 GitHub Actions 实战案例串联起来。无论你是刚接触 Git 的新手，还是已经在用 CI/CD 但对 checkout 行为理解不够透彻的开发者，这篇文章都值得收藏备用。

1. 背景与核心概念

1.1 什么是 Git Checkout

git checkout是 Git 提供的一个多功能命令，主要用于两种场景：

  • 切换分支：把当前工作目录切换到另一个分支上，让工作区文件与目标分支保持一致。
  • 恢复文件：把某个文件或目录恢复到指定提交时的状态，常用于丢弃本地修改。

用一句话概括，git checkout的核心职责是“改变当前工作区的状态”，让它指向你想要的提交、分支或文件内容。

举个例子，假设你正在feature/login分支上开发登录功能，产品经理临时让你去修复一个线上 Bug。你需要先切回main分支：

git checkout main

执行后，本地工作区的文件会从feature/login的内容变为main分支的内容，接下来你就可以基于主干代码创建修复分支了。

1.2 什么是 actions/checkout

actions/checkout是 GitHub Actions 官方提供的 Action，作用是在 CI/CD 工作流运行时，把指定的仓库代码拉取到运行器（Runner）的工作目录中。

简单来说，GitHub Actions 的工作流运行在一个全新的虚拟环境里，这个环境默认是空的。如果你想让流水线编译代码、运行测试、构建镜像，第一步必须先把代码拉下来。actions/checkout就是干这件事的。

steps: - name: 拉取代码 uses: actions/checkout@v4

这行配置在整个 GitHub Actions 工作流中的地位，等同于本地开发时打开终端先执行git clone。

1.3 两者的核心区别

对比项git checkoutactions/checkout
使用场景本地 Git 操作GitHub Actions 工作流
核心作用切换分支、恢复文件把仓库代码拉取到运行器
执行位置本地终端GitHub 托管的 Runner 或自托管 Runner
是否需要网络操作本地仓库，切换分支通常不需要远程交互需要从 GitHub 拉取远程仓库
对应关系Git 原生命令一个封装好的 Action 组件

很多人在配置 GitHub Actions 时，会把这两个概念混在一起，认为“checkout 就是切换分支”，导致对工作流的行为判断失误。实际上，actions/checkout里虽然取名为 checkout，但它做的事情更接近git clone加git checkout的组合操作。

1.4 为什么开发者需要掌握这两个工具

从实际开发效率来看，git checkout是日常版本管理的必修课，掌握它能让你在分支切换、代码回退、临时修复上游 Bug 等场景中游刃有余。而actions/checkout是 CI/CD 自动化的基础操作，理解它的参数和行为，才能正确配置流水线，避免“本地能构建，CI 却失败”的经典问题。

2. 环境准备与版本说明

在开始具体操作之前，先确认一下环境要求。

2.1 Git 版本

本文涉及的git checkout命令是 Git 的稳定功能，几乎任意版本都支持。部分新命令如git switch和git restore是 Git 2.23 版本引入的，如果你希望体验更细分的新命令，建议 Git 版本不低于 2.23。

查看当前 Git 版本：

git --version

输出示例（版本需根据你的实际情况调整）：

git version 2.43.0

如果你的版本较旧，可以使用包管理器升级。本文示例以常见环境为主，重点演示命令思路。

2.2 GitHub Actions 环境

使用actions/checkout需要满足以下条件：

  • 一个 GitHub 仓库。
  • 仓库开启了 GitHub Actions 功能。
  • 运行器可以是 GitHub 托管的ubuntu-latest、windows-latest、macos-latest，也可以是自托管 Runner。

关于版本，目前actions/checkout的最新稳定版本以 v4 为主，但具体版本号会持续更新。本文示例采用actions/checkout@v4，如果你的项目有特殊兼容性要求，可以锁定到更具体的版本，例如actions/checkout@v4.1.1，或使用提交 SHA 锁定版本以保证供应链安全。

2.3 示例项目结构

为了便于后续实战演示，我先创建一个示例项目。假设项目名称为demo-checkout，目录结构如下：

demo-checkout/ ├── .github/ │ └── workflows/ │ └── ci.yml ├── src/ │ └── main.py └── README.md

其中，.github/workflows/ci.yml是 GitHub Actions 的工作流配置，src/main.py是一个简单的 Python 文件，用于验证代码拉取和分支切换效果。

3. Git Checkout 核心用法与原理拆解

这一节会详细拆解git checkout的常见用法，并且通过示例说明每条命令的适用场景和注意事项。

3.1 切换分支

最基础也是最常用的用法，是从当前分支切换到目标分支。

git checkout dev

执行成功后，本地分支指针会指向dev分支的最新提交，工作区文件也会同步更新。这里的原理是：Git 会根据目标分支的提交记录，更新暂存区和工作目录，使它们与dev分支顶部的提交保持一致。

如果目标分支在远程仓库存在，但本地还没有对应的分支，可以用下面这种更简便的写法：

git checkout -b dev origin/dev

这个命令做了两件事：

  • -b表示创建新分支。
  • 新分支dev会跟踪远程分支origin/dev。

执行后，本地会新增一个dev分支，并与远程dev分支建立跟踪关系，后续git pull会自动从远程拉取更新。

3.2 创建并切换分支

在日常开发中，从主干切出一个新功能分支非常常见：

git checkout -b feature/payment

该命令等价于先执行git branch feature/payment，再执行git checkout feature/payment，一步完成创建和切换。

这里需要特别注意一点：git checkout -b是基于当前 HEAD 指向的提交来创建新分支的。如果你当前在main分支上，新分支也会以main的最新提交为起点。

如果想基于某个历史提交或远程分支创建新分支，可以追加起始点：

git checkout -b fix-bug a1b2c3d

其中a1b2c3d是某个提交的哈希前缀。这种方式常用于从历史版本拉出修复分支。

3.3 丢弃工作区的修改

当你修改了某个文件后又想放弃这些修改，可以这样做：

git checkout -- src/main.py

这行命令的作用是：把src/main.py恢复为暂存区或 HEAD 中的版本，覆盖当前工作区的修改。

原理说明：git checkout -- <file>会把文件内容从索引（暂存区）复制到工作目录。如果该文件没有暂存过修改，那么最终内容会与 HEAD 提交保持一致。

操作示例：

# 先修改文件 echo "print('bug')" >> src/main.py # 查看状态 git status # 丢弃修改 git checkout -- src/main.py # 再次查看状态，修改已被撤销 git status

使用这个命令时要非常小心，因为被覆盖的修改无法通过 Git 找回。如果文件修改较多，建议先用git stash暂存一下，而不是直接丢弃。

3.4 切换到历史提交（Detached HEAD 状态）

有时候我们需要查看某个历史版本的代码，可以用分支名加git checkout，也可以直接指定提交哈希：

git checkout a1b2c3d

执行后，Git 会提示你正处于detached HEAD状态。意思是：当前 HEAD 不指向任何分支，而是直接指向一个具体的提交。在这个状态下，如果你继续修改并提交，新提交不属于任何分支，一旦切换到其他分支，这些提交很容易丢失。

如果需要基于这个历史提交做修改，正确的做法是新建一个分支：

git checkout -b feature/fix-from-history a1b2c3d

这样就可以在历史版本上安全地开发了。

3.5 Git 2.23 之后的新选择：switch 与 restore

git checkout承担了太多职责，导致命令语义不够清晰。Git 2.23 之后，官方给出了更细分的两个命令：

  • git switch：只负责分支切换。
  • git restore：只负责文件恢复。

示例对比：

# 老方式 git checkout dev git checkout -- src/main.py # 新方式 git switch dev git restore src/main.py

新命令让“切分支”和“恢复文件”在语义上彻底分开，更不容易误操作。不过，git checkout依然被广泛使用，因为它兼容旧脚本，而且在很多老项目的文档中依然占主导地位。你在网上搜索到的老教程可能还是 checkout 为主，新项目则建议逐步切换到 switch 和 restore。

3.6 常见误区：checkout 与 clone、reset 的区别

很多新手容易混淆checkout、clone、reset三者的区别：

命令作用范围典型场景
git clone从远程仓库拷贝整个仓库到本地首次获取代码
git checkout切换分支、恢复文件、切换提交日常分支操作
git reset移动当前分支的 HEAD 指针，可重置暂存区和工作区撤销提交、取消暂存

简单来说，clone是“从无到有”，checkout是“切换状态”，reset是“重置状态”。理解这三者区别，可以避免很多误操作。

4. Actions/Checkout 核心配置与参数拆解

理解了本地 Git 的checkout之后，我们再来看 GitHub Actions 里的actions/checkout。虽然名称相似，但它是一个独立的 Action 组件，需要放在工作流的steps中使用。

4.1 基本用法

在一个最基本的 GitHub Actions 工作流中，拉取代码只需要三行配置：

name: CI on: push: branches: [ main ] jobs: build: runs-on: ubuntu-latest steps: - name: 拉取代码 uses: actions/checkout@v4

这段配置的意思是：当main分支收到 push 事件时，在ubuntu-latest运行器上执行一个名为build的任务，第一步就是通过actions/checkout@v4拉取当前仓库代码。

执行完成之后，运行器的工作目录$GITHUB_WORKSPACE下就是完整的仓库文件，后续步骤可以直接操作这些文件。

4.2 常用参数详解

actions/checkout提供了多个参数，用于控制拉取行为。下面是实际项目中最常用的几个：

repository

指定要拉取的仓库地址，默认值是当前触发工作流的仓库。如果你需要拉取同一个组织下的另一个仓库，可以设置为：

- uses: actions/checkout@v4 with: repository: my-org/another-repo
ref

指定要检出的分支、标签或提交 SHA。默认值是触发工作流的事件对应的 ref。例如 push 事件触发时，默认就检出那个被 push 的分支。

如果你希望固定拉取main分支最新代码，可以写成：

- uses: actions/checkout@v4 with: ref: main

如果你想拉取某个特定 tag：

- uses: actions/checkout@v4 with: ref: v1.0.0

如果你想拉取某个具体的提交：

- uses: actions/checkout@v4 with: ref: a1b2c3d
fetch-depth

控制 Git 拉取的历史提交深度。默认值是 1，也就是只拉取最新一条提交记录，目的是加快拉取速度、减少 CI 耗时。

如果你的流水线需要完整的 Git 历史，例如在版本发布时需要生成 Changelog，或者需要比较两个分支之间的提交数，可以设置为0表示拉取全部历史：

- uses: actions/checkout@v4 with: fetch-depth: 0

这里特别提醒：设置fetch-depth: 0会显著增加拉取时间，尤其是大型仓库。请根据实际需求选择，不要盲目设置为 0。

path

指定代码检出到运行器工作目录的哪个子目录。默认检出的位置是$GITHUB_WORKSPACE根目录。如果你希望把代码放到子目录中，或者在一个任务中拉取多个仓库，可以这样配置：

- uses: actions/checkout@v4 with: path: main-repo

执行后，代码会被放进$GITHUB_WORKSPACE/main-repo目录。

token

指定用于拉取仓库的访问令牌。默认值是GITHUB_TOKEN，这是 GitHub Actions 自动生成的临时令牌，权限范围仅限于当前仓库。

如果你需要拉取私有仓库，或者需要在工作流中执行写操作（例如提交代码回仓库），可以使用自定义的 Personal Access Token（PAT）：

- uses: actions/checkout@v4 with: token: ${{ secrets.MY_PAT }}

需要强调的是，使用 PAT 时要遵循最小权限原则，只授予当前工作流所需的最小权限，并把令牌保存在仓库的 Secrets 中，不要明文写在配置文件里。

persist-credentials

控制是否将 Git 认证信息持久化到本地配置中。默认值是true，也就是说，工作流中后续执行git push时可以复用认证信息。

如果你不希望把令牌暴露给工作流中的其他步骤，可以设置为false：

- uses: actions/checkout@v4 with: persist-credentials: false

设置之后，后续步骤如果需要git push，就需要手动配置凭据。

clean

控制检出之前是否清理工作目录中未跟踪的文件。默认值为true，即每次会强制清理工作目录，确保代码干净。如果同一个工作流中需要跨步骤保留构建产物，可以考虑设置为false。

4.3 actions/checkout 与 git checkout 的对应关系

为了加深理解，这里列出actions/checkout内部的大致行为（基于 v4 的默认配置）：

  1. 创建一个临时目录。
  2. 执行git init初始化仓库。
  3. 添加远程仓库地址origin，指向当前仓库地址。
  4. 执行git fetch拉取指定ref对应的提交。
  5. 执行git checkout检出该提交或分支。
  6. 把仓库地址写入本地配置，方便后续git push等操作。

所以，actions/checkout内部确实也调用了 Git 命令，但它在运行器环境中完成的是“从零拉取代码”的流程，与本地已有的 Git 仓库上执行git checkout完全不是一回事。

5. 完整实战案例：用 GitHub Actions 拉取代码并构建验证

这一节带大家完成一个完整的 GitHub Actions 工作流，覆盖拉取代码、查看分支、构建验证、提交构建结果四个常见场景。

5.1 创建示例项目

首先在 GitHub 上创建一个仓库demo-checkout，然后在本地克隆到工作目录：

git clone https://github.com/<your-username>/demo-checkout.git cd demo-checkout

创建src/main.py文件，内容如下：

# 文件路径：src/main.py def main(): print("Hello, actions/checkout!") if __name__ == "__main__": main()

创建README.md：

# demo-checkout 一个用于演示 actions/checkout 用法的示例项目。

5.2 创建工作流文件

在项目根目录创建.github/workflows/ci.yml文件：

name: CI Demo on: push: branches: [ main ] workflow_dispatch: jobs: build: runs-on: ubuntu-latest steps: - name: 拉取仓库代码 uses: actions/checkout@v4 - name: 查看当前目录结构 run: | pwd ls -la - name: 查看当前分支 run: | git branch -a git log --oneline -3 - name: 运行 Python 脚本 run: python3 src/main.py - name: 拉取特定分支代码（示例） if: github.ref == 'refs/heads/main' uses: actions/checkout@v4 with: ref: main fetch-depth: 0

这个工作流做的事情依次为：

  1. 使用默认参数拉取代码。
  2. 查看运行器当前目录。
  3. 查看拉取到的分支和最近提交。
  4. 运行 Python 脚本验证代码可用性。
  5. 再次拉取main分支完整历史，演示fetch-depth参数。

5.3 推送到 GitHub 并触发工作流

本地提交并推送：

git add . git commit -m "feat: add demo project and CI workflow" git push origin main

推送成功后，在 GitHub 仓库页面点击Actions标签页，可以看到名为CI Demo的工作流正在运行。

5.4 查看运行结果

点击运行记录，可以看到每个步骤的执行状态和日志输出。预期结果：

  • 查看当前目录结构步骤会输出工作目录路径和文件列表，包括.github、src、README.md。
  • 查看当前分支步骤会输出分支信息，默认情况下检出的分支是main。
  • 运行 Python 脚本步骤会输出Hello, actions/checkout!。
  • 拉取特定分支代码步骤再次拉取代码，由于fetch-depth: 0，会拉取完整的 Git 历史。

5.5 在同一个任务中拉取两个仓库

实际项目中，一件事务可能需要多个仓库的代码。actions/checkout支持在同一个 job 中多次使用，通过path参数区分目录：

jobs: build: runs-on: ubuntu-latest steps: - name: 拉取主仓库 uses: actions/checkout@v4 with: path: main - name: 拉取配置仓库 uses: actions/checkout@v4 with: repository: my-org/config-repo token: ${{ secrets.MY_PAT }} path: config

执行后，运行器工作目录下会有main和config两个子目录，分别存放两个仓库的代码。这种方式非常适合“代码与配置分离”的部署方案。

6. 常见问题与排查思路

在实际使用中，actions/checkout和git checkout都可能遇到各种报错。下面梳理几个高频问题。

6.1 常见问题汇总

问题现象常见原因解决思路
工作流报错：Repository not found仓库不存在，或当前 Token 无权限访问私有仓库检查仓库地址；为私有仓库配置 PAT 并放入 Secrets
工作流报错：refs/heads/main was not found指定的 ref 分支名不正确确认远程仓库的分支名，使用git branch -r查看远程分支
本地执行git checkout提示pathspec did not match分支名或文件路径拼写错误使用git branch -a查看全部分支名，确认分支存在
本地工作区修改被覆盖执行了git checkout -- <file>或切换到其他分支导致冲突切换分支前先git stash或提交当前修改
fetch-depth: 1导致无法查看历史提交只拉取了最新一条提交根据需求设置为0或更大的数字
后续步骤无法执行git pushpersist-credentials设置为 false，或令牌无写权限检查令牌权限，或手动配置 Git 认证信息
检出目录与预期不一致使用了path参数，代码不在根目录调整后续命令的目录，使用cd <path>定位

6.2 典型问题排查：actions/checkout 无法拉取私有仓库

现象：

remote: Repository not found. fatal: repository 'https://github.com/my-org/private-repo.git/' not found

原因：

GITHUB_TOKEN默认只对当前仓库有权限。如果actions/checkout指定的repository是另一个私有仓库，这个默认令牌可能无法访问。

排查步骤：

  1. 确认目标仓库确实存在，并且当前账号有访问权限。
  2. 检查工作流中是否配置了token参数。
  3. 如果没有，创建一个具有repo权限的 PAT。
  4. 将 PAT 添加到仓库的 Secrets 中，命名为MY_PAT。
  5. 修改工作流配置。

修复示例：

- uses: actions/checkout@v4 with: repository: my-org/private-repo token: ${{ secrets.MY_PAT }}

6.3 典型问题排查：本地 checkout 后代码丢失

现象：

在分支切换后，发现某个本地文件的修改不见了。

原因：

如果工作区有未提交的修改，且目标分支与当前分支在该文件上存在差异，git checkout默认会阻止切换（防止覆盖）。但如果你先执行了git checkout -- <file>，或者修改的文件恰好没有冲突，Git 可能直接完成了切换，导致未提交的修改丢失。

排查与避免方法：

  1. 切换分支前使用git status查看工作区状态。
  2. 若有未提交修改，优先执行git stash。
  3. 切换完成后再执行git stash pop恢复修改。

示例：

git stash git checkout dev # 在 dev 上进行操作 git stash pop

这样可以最大程度避免代码丢失。

7. 最佳实践与工程建议

结合社区经验和实际项目踩坑，这里给出一些关于checkout相关操作的最佳实践建议。

7.1 Git Checkout 使用建议

保持分支整洁

在本地开发时，功能分支建议从最新的主干代码拉出。在创建分支之前，先执行：

git checkout main git pull origin main git checkout -b feature/xxx

这样确保新分支基于最新主干代码，减少后期合并冲突。

谨慎使用强制覆盖

不要轻易使用git checkout -- .强制丢弃所有工作区修改。如果确实需要清理，建议先使用git stash暂存，给自己留一条后悔路。

逐步采用新命令

新项目或者团队规范允许的情况下，尽量使用git switch和git restore。语义清晰、不易出错，而且命令行提示也更加友好。

git switch -c feature/xxx git restore src/main.py

7.2 Actions/Checkout 使用建议

锁定版本以保证稳定性

actions/checkout@v4是常见写法，但如果你的项目对供应链安全要求较高，建议锁定到具体的 tag 或提交 SHA。例如：

- uses: actions/checkout@v4.1.1

或者使用完整 SHA：

- uses: actions/checkout@<commit-sha>

锁定版本可以避免上游 Action 升级带来的不可控变化，但需要定期评估是否有必要升级。

谨慎设置 fetch-depth

fetch-depth: 0会拉取整个仓库历史，对于大型仓库来说非常耗时。只有在工作流确实需要完整历史时（例如生成版本号、比较提交数、执行git log等操作）才使用。大多数构建和测试场景，默认的fetch-depth: 1就足够了。

注意 token 权限最小化

actions/checkout默认使用GITHUB_TOKEN，它已经能满足大部分场景。只有在需要跨仓库访问或写回操作时，才使用自定义 PAT。而且 PAT 要保存在 Secrets 中，避免泄露。

善用 path 参数管理多仓库

在一个工作流中拉取多个仓库时，用path参数严格隔离目录，避免不同仓库的代码相互覆盖。后续步骤操作代码时，注意工作目录的切换。

- name: 操作配置仓库 working-directory: ./config run: | ls -la

7.3 CI 安全与生产环境注意事项

在执行涉及git push或写回仓库的工作流时，请务必注意：

  • 不要在日志中打印 Token 或敏感信息。
  • 推送代码前检查目标分支，避免误推。
  • 生产环境使用的 Actions 尽量锁定版本，并定期检查上游更新。
  • 需要变更生产环境时，先在小范围验证，再逐步推广。

GitHub 官方文档也建议在 Actions 中使用permissions字段来限制GITHUB_TOKEN的权限。例如，一个只需要读代码的 job，可以这样配置：

jobs: build: runs-on: ubuntu-latest permissions: contents: read steps: - uses: actions/checkout@v4

这样即使 Token 泄露，攻击者也无法利用它向仓库写入内容。

8. 总结与进一步学习方向

本文围绕actions/checkout和git checkout两个核心概念，梳理了从本地 Git 操作到 GitHub Actions 自动化的完整链路。

重点内容回顾：

  • git checkout是本地 Git 的多功能命令，用于切换分支、恢复文件、切换历史提交。
  • actions/checkout是 GitHub Actions 中的官方 Action，用于在运行器中拉取仓库代码。
  • 两者虽然名称相似，但职责完全不同。
  • 理解actions/checkout的常用参数（repository、ref、fetch-depth、path、token、persist-credentials），是配置 CI 流水线的基础。
  • 常见坑点集中在 token 权限、分支名错误、fetch-depth 影响历史获取、以及本地 checkout 时未提交修改丢失等场景。

如果你是新手，下一步可以继续学习 Git 的分支管理流程，特别是git merge和git rebase的区别；如果你已经在使用 GitHub Actions，可以深入研究 Workflow 的触发事件、矩阵构建、缓存机制以及自定义 Action 的编写方法。

实际项目中，使用actions/checkout时优先保持简单配置，按需增加参数；使用git checkout时牢记“有未提交修改要先 stash”。把基础命令和 CI 流程都练熟之后，你会发现从本地开发到自动化部署的整条链路会顺畅很多。

http://www.cnnetsun.cn/news/4336475.html

相关文章：

  • Spring Boot服装生产管理系统：从设计到部署完整解析
  • PANDA原型锚定对齐：解决医学多模态部分未配对难题的方法解析
  • 工厂抖音推广效果验收体系：有效询盘定义、ROI测算公式与八步验收SOP
  • 2026年最新 找专业国密门禁企业认准这3点就行
  • Hypermesh入门指南：从几何清理到网格划分的前处理全流程
  • 顺丰科技测试笔试高频考点复盘：从基础到自动化的完整地图
  • 基于STM32的太阳能MPPT控制器：从原理到实战全解析
  • StreamCore：开源实时语音AI基础设施的架构与实战解析
  • # (免费领源码）SpringBoot+Vue 协同办公系统‑计算机毕设 JAVA、PHP、python、数据集、APP、小程序、C#C++、单片机、网络工程、大数据、全套文案
  • 工业传感器与变送器详解：13 工业传感器与Modbus/CAN/工业以太网
  • AI Agent 工程实践（37）：需求分析——一个 Agent 项目到底应该怎么拆
  • DeepSeek 涨价 3.4 倍，我算完账决定不换模型——峰谷差 2 倍、缓存差 30 倍，但真正更省钱的是那个「2 倍」
  • 基于MATLAB的复式断面水位-流量关系曲线计算与绘制
  • 从毕业设计管理系统看Spring Boot全流程开发与答辩实践
  • 用TypeScript类型系统重构条件工作流：从if/else到可辨识联合
  • 需求验证，评审和测试
  • MFC定时器与列表框实操：实现Windows桌面应用动态刷新
  • 恒温测控上位机开发实战：C# Winform串口通信与PID控制完整方案
  • 语音识别+AI重命名：视频文件批量智能改名实战指南
  • 人形机器人夺冠背后：从炫技到工程化稳定落地
  • 基于ROS2的四轮差速机器人运动控制与自主导航仿真全流程解析
  • Web之HTML5
  • 故障定位手段
  • 基于STM32和MPU6050的跌倒检测系统设计与实现
  • 基于YOLOv8的固定翼无人机检测与PyQt可视化实战
  • 从Linux到SRE：大厂运维开发笔试实战解析
  • WPF Viewport3D 3D图片预览特效实战：翻转、旋转木马与性能优化
  • TextGen 本地大模型部署实战：从克隆到 API 调用的完整路线
  • 基于STM32的智能家居控制系统设计：红外遥控空调实现详解
  • Umi-OCR 离线文字识别指南：免费、可批量的一站式 OCR 方案