直接给大家伙儿一个实用得不能再实用的东西，关于从 GitHub 上把代码搞下来这件事儿。相信不管是刚入行的新人，还是写了几年代码的老手，都遇到过这种场景：看到一个开源项目，想 clone 完整代码，结果仓库巨大无比，等得头发快白了；或者你只想要其中一个文件夹里的功能，却被迫把整个项目下载下来；更有甚者，只需要读某一个配置文件，也要把整个仓库糊到本地。这标题看着简单，其实里面的门道还真不少，我这次把完整项目、某个文件夹、单个文件这三种下载姿势，通通盘一遍。
先说清楚这篇内容能解决什么问题，适合谁看。如果你动手能力还行，但对 Git 的理解停留在git clone和git push阶段；如果你经常需要快速查看某个开源项目，但不想每次都把几十 GB 的依赖和历史记录拖下来；如果你只需要别人项目里的一个配置文件、一张图片、一份文档，却只能干瞪眼——那这篇文章就是给你准备的。从最基本的原理，到实操命令，再到我踩过的一些坑，一次讲透。
1. 先搞明白你要下载的到底是什么东西
1.1 三种下载需求背后的真实场景
很多人会习惯性地觉得，从 GitHub 下载东西，不就是git clone吗？这个想法本身没毛病，但它把问题想简单了。我们面对的真实场景其实分三种，对应不同的技术选型。
第一种：完整项目代码。这种需求往往出现在你想深度研究某个开源项目、想在自己的代码里引入它的全部功能、或者想为这个项目提交代码的时候。这时候你需要的不只是当前的一份快照，你还需要完整的 Git 历史记录，需要能自由切换分支、打标签，甚至你需要关联上游仓库进行二次开发。这是最深度的下载方式，也是唯一能让你真正“拥有”这个项目的方式。
第二种：某个文件夹。这种需求特别多，我自己经常碰到。比如说你看到某个前端项目里有一套写得很好的 SCSS 变量规范，你想直接拿来用；又比如你想参考某个项目里的docs目录，看它的架构文档是怎么组织的；再比如你只想要项目里utils工具函数文件夹里的几个封装好的方法。这种需求下，你把整个仓库 clone 下来其实是相当浪费的，因为咱只是要里面一小部分资源，根本不需要历史记录。
第三种：单个文件。这种需求就更细碎了。你经常会在技术文章里看到作者说“可以参考这个项目的package.json”，或者“这个配置文件nginx.conf写得很好”。你想做的就是把它下载下来，打开看看。这种需求如果还走 Git 那套完整流程，就是杀鸡用牛刀了。
我把这三种需求拎清楚，是因为接下来要讲的每一个方案，都是围绕“你到底拿到了什么”这个核心来展开的。下载一个东西，不只是“把文件搞到硬盘上”，你要搞清楚拿到的是文件的快照，还是带着历史记录的版本控制数据。这两者背后的体积差异、可用性差异、以及后续操作的灵活性差异，天差地别。
1.2 为什么无脑 clone 最不可取
这是我最想吐槽的一点。很多新手教材上来就跟你说git clone <仓库地址>，然后就没有然后了。对一个小型文档仓库来说，这么干没问题。但如果你遇到的是那种积累了五六年、提交了几万个 commit 的大型项目，完整的 clone 动辄好几个 GB，里面绝大部分体积都是.git目录里的历史记录。这些历史记录你百分之九十九都不会去翻看，它们却白白占着你硬盘、消耗着你的下载时间。
这里插一句，生活化类比一下。完整 clone 一个仓库，相当于你在逛一个巨大的线上书城，你明明只想买一本书，结果系统强制你把这个书城从建站第一天起所有的订单记录、商品改动历史、每一版网站源码全部打包下载到本地，而你只需要读那一本书的当前版本。你说这叫什么事儿。
所以，在动手之前，先问自己一句：我要下载这个东西，是拿来干嘛的？是为了研究、为了用、还是为了参考。这个问题想清楚了，下面的所有操作都跟着变。这也是这篇文章真正想教给你的核心思维——在开源项目获取这个环节，选择比努力更重要。
2. 完整项目克隆：不只是git clone那点事
2.1 基础命令与核心参数解析
如果你确认就是要完整地拿到这个项目，要提交代码、要切换分支、要以后都能git pull拉取更新，那git clone就是正解。但即便是这个最基础的命令，参数选不对，体验也天差地别。
最基础的用法是这样：
git clone https://github.com/某用户名/某仓库.git这个命令干的事情相当直白：Git 会先链接远程服务器，然后下载这个仓库的所有远端对象——包括所有分支的引用、所有标签、完整的提交历史，然后在本地生成一个工作目录。目录名字默认就是你仓库的名字，你也可以在命令末尾再加一个参数指定目录名：
git clone https://github.com/某用户名/某仓库.git 我的本地目录在实际使用中，顶多一成的场景会用到这种纯默认命令。更多时候我们会搭配几个非常关键的参数，下面列几个我用得最多的。
--depth=1参数，这就是网上说的“浅克隆”。它做的事情是只拉取最近一次提交对应的文件快照，不拉取历史提交记录。这样下来，仓库体积能缩小非常多，特别适合你只是想看一眼代码、或者打算在这个基础上另起炉灶做二次开发的场景。注意，浅克隆是会牺牲掉切换历史分支的能力的，因为历史被截断了。
--branch 分支名参数，用于指定克隆某个具体分支，而不是默认分支。一个大型仓库可能同时维护着main、develop、release/v2.0等多个分支，每个分支的内容可能差异巨大，有这个参数就方便多了。跟--depth=1搭配使用，能非常轻量地拿到一个指定分支的最新快照：
git clone --depth=1 --branch=develop https://github.com/某用户名/某仓库.git--recursive参数，用于递归拉取子模块。有些项目会使用submodule来管理外部依赖，表面上你 clone 下来了，但里面的子模块目录是空的，必须加上这个参数或者 clone 完成后执行git submodule update --init --recursive才能把依赖拉全。我见过不少小型团队不重视子模块的维护，导致别人 clone 后总是少东西，这属于项目维护层面的问题，但下载者这边记住加参数就对了。
还有一个我觉得非常值得一提的进化版下载方式：--filter=blob:none。这个参数配合部分克隆（partial clone）特性，可以让 Git 先下载提交历史和目录结构，但不下载文件内容（blob 对象），当你真正需要某个文件的时候再按需从服务器拉取。这个在实际使用中体验极好，因为 Git 刚开始的下载速度极快，你的工作区看起来是正常的，但底层文件内容是懒加载的。
2.2 什么场景该选浅克隆，什么场景必须全量克隆
浅克隆是个好东西，但它不适合所有场景。我以自身的经验给你划一条线，你在实际操作前内心过一遍。
如果你的目标是：把项目 fork 下来，提交 pull request 回去；或者要追踪这个项目的长期更新，持续同步上游；或者需要仔细研究某次关键提交的 diff，判断它在哪个 commit 种下了 bug——那你必须用完整克隆。因为浅克隆的仓库缺乏历史节点，Git 无法建立远端分支和本地分支的追踪关系，后续git fetch就会比较麻烦，虽然现在稍微好一些了，但终究不如完整克隆省心。
如果你的目标是：把别人的代码拿下来编译一下、跑起来看看效果；或者想基于某个开源项目做定制化修改，不想保留原来的 Git 历史；或者只是想评估这个项目质量几何——那完全没必要全量克隆。使用--depth=1浅克隆是你的最佳选择。
实测下来，同样的一个大项目，全量克隆可能要下载 2 GB 数据，浅克隆往往只需要几十 MB 到一两百 MB。这个差异是非常直观的，前提是你的网络环境足够通畅，下载速度上去了，才能体会到这种省时省力的快感。
另外还有一个容易忽略的点，当项目里包含了大型二进制资源的时候，历史记录里很可能藏着很多早已废弃的资源文件。这种情况全量克隆的体积会爆炸，浅克隆的优势就更加明显了。我遇到过一次，一个项目的仓库体积到了 8 GB，里面 95% 都是历史遗留的安装包资源，当前最新快照只有 200 MB。这种情况你用浅克隆，10 分钟解决问题，用完整克隆，你是不是傻。
2.3 实操里的几个细节与避坑思路
先说断点续传的问题。Git 本身的传输机制设计得不太适合 HTTP 环境下的断点续传，如果你下载到一半断网了，git clone会直接报错，从头再来。我自己的实战教训是，如果仓库特别大，网络又不稳定，可以先做一次裸克隆，把 Git 仓库的数据拉下来，再单独执行 checkout：
git clone --mirror https://github.com/某用户名/某仓库.git 临时目录.git然后基于这个临时目录重新建立工作区：
git clone 临时目录.git 最终目录这样做的好处是，第一个步骤纵然失败了，因为用的是--mirror，远端的引用和对象已经完整拉到本地了。第二步本质上是本地复制，速度极快。如果第一次最终还是没拉完，最多重新执行一次第一步，但由于 Git 的本地对象库已经有了部分对象，重试的时候不会全部重新下载——Git 会根据已存在的对象做增量传输，这样能省掉不少流量。
再说一个路径中含中文或者空格的坑。有些仓库名很拗口，用户在克隆的时候喜欢直接手打 URL，结果因为标签带括号在 shell 里被解析成了特殊字符，导致克隆失败。我的建议是，所有 URL 一律用英文引号包起来。这个习惯能让你避免很多莫名其妙的报错。
最后说说大仓库 clone 卡住的问题。很多人在网络环境不好的情况下会遇到 clone 到一半卡死的现象，这其实是 Git 的 HTTP 缓冲区设置得不够大。解决方案是调大http.postBuffer值：
git config --global http.postBuffer 524288000这个命令把缓冲区调到了 500 MB，实测对解决某些超时问题非常有效。这里的原理是，Git 在通过 HTTP 协议传输数据时，如果单次发送的数据量超过缓冲区大小，连接就会被迫断开，调大数据量上限自然能减少断连几率。这不算什么高级技巧，但确实是我见过频率最高的大仓库失败原因之一。
3. 只想下载某一个文件夹，别把整个仓库拖下来
3.1 方案一：SVN 方式取目录
是的，你没看错。虽然 GitHub 是一个 Git 托管平台，但它对外提供的下载接口里，一直保留着对 SVN 协议的支持。利用这个特性，我们可以优雅地只下载仓库里的某一个子目录，而不用把整个仓库 history 都拉到本地。
具体做法是利用 GitHub 提供的trunk路径，把仓库地址这样组装：
svn export https://github.com/某用户名/某仓库/trunk/某个/子目录注意这里的路径逻辑，trunk对应的是仓库的默认分支。如果项目的默认分支是main或者master，在 SVN 视角里它统一表现为trunk。如果你需要的目录不在默认分支上，那就用分支名替换trunk，比如：
svn export https://github.com/某用户名/某仓库/branches/分支名/某个/子目录svn export这个命令会直接导出一个干净的目录副本，不包含任何.svn元数据。这意味着你下载下来的就是纯文件，不会副带一堆版本控制文件夹，用起来非常清爽。使用这套方案的前提是你本地装了 SVN 命令。在 macOS 和很多 Linux 发行版上，SVN 并不默认安装，需要你通过包管理器装一下，在 Windows 上则需要去官网下载安装包。
这个方案最核心的优势是：下载速度极快，只传输你需要的目录的当前快照，完全没有多余花销。缺点是你拿不到 Git 历史，无法用 Git 维护这个目录的后续变更。不过话说回来，你都选择只下载一个文件夹了，还要什么 Git 历史，压根用不上。
3.2 方案二：利用开源下载工具
如果你不想装 SVN 那一套东西，还有一个更省事儿的方案。GitHub 上有一个非常受欢迎的第三方工具项目，专门用来做“只下载指定文件夹”这件事，通常以网页服务的形式提供。你只需要在浏览器里打开那个工具网站，把 GitHub 仓库的文件夹页面链接粘贴进去，点击下载，就能拿到一个 zip 压缩包。
它的工作原理其实很简单：先到 GitHub 的 API 接口上递归获取目标文件夹下的所有文件列表和下载链接，然后逐个请求文件的原始内容，最后在内存中打包成 zip 返回给浏览器。这个过程完全不需要你在本地配置任何环境，一个浏览器就能搞定。
这个方案的好处显而易见：零门槛、可视化、不怕记错命令。坏处也很明显：如果目标文件夹里文件数量特别多（成千上万），它需要发起很多次 HTTP 请求，打包过程会相当慢，而且因为中间经过了第三方服务器中转，你对下载过程的把控力其实是弱的。此外，这类工具对于超大文件的跳过策略做得一般，如果你文件夹里有 1 GB 以上的单体大文件，很可能下载失败。
我自己的使用建议是：适用于文件数量在两三百个以内的中小型文件夹。如果你要下载的文件夹非常大、文件非常多，还是回到 SVN 方案更稳当。
3.3 方案三：Git 稀疏检出（Sparse Checkout）
这个是我个人最喜欢的方案，因为它用起来最干净，而且完全不需要安装任何额外工具，只要本地 Git 版本不算太老就能用。稀疏检出的核心思想是：让 Git 在 checkout 工作区文件的时候，只把某些路径下的文件真正写到磁盘上。
操作流程如下：
# 第一步：正常初始化一个空的 Git 仓库 git init 目标文件夹 # 第二步：进入目录，设置远程仓库地址 cd 目标文件夹 git remote add origin https://github.com/某用户名/某仓库.git # 第三步：开启稀疏检出模式 git sparse-checkout init --cone # 第四步：设置只希望检出的目录 git sparse-checkout set 某个/子目录 # 第五步：拉取代码 git pull origin main这套流程跑完，你当前目录下只会有某个/子目录里的文件，其他所有文件都不会出现在你的工作区。如果你以后又想加一个目录出来，执行：
git sparse-checkout add 另一个/子目录它就能把新目录也扩展出来。
为什么要推荐这种方式？因为它兼具了 SVN 方案的轻量，又保留了 Git 的完整能力。你在本地仍然是一个完整的 Git 仓库，可以随时git pull拉取目标分支的最新变更。对于那种“现在只需要这个目录，但以后可能要别的目录”的场景，稀疏检出简直完美。
需要注意一个细节：尽管你只 checkout 了一部分文件，但git pull的时候，Git 仍然可能需要下载你尚未 checkout 的目录的提交对象。因为 Git 的对象数据库是完整的，文件内容懒加载只是在 checkout 步骤被控制住了。所以如果你的仓库特别大，这个方案在传输量上不如 SVN 方案极致。但对绝大多数仓库来说，这个开销是可以接受的，而且换来的是操作的灵活性和一致性。
3.4 三种方案的对比与选择
为了让你看得更清楚，我把这三种方案放在一起做一个快速的横向对比：
| 判断维度 | SVN 导出 | 第三方下载工具 | Git 稀疏检出 |
|---|---|---|---|
| 额外依赖 | SVN 客户端 | 浏览器即可 | 仅 Git |
| 下载体积 | 极小，只含目标目录 | 极小，只含目标目录 | 适中，含部分 Git 对象数据 |
| 是否可拉取更新 | 不可以，需重新导出 | 不可以，需重新打包 | 可以，等同于完整仓库 |
| 适合目录规模 | 大中规模目录 | 中小规模目录 | 任意规模 |
| 操作复杂度 | 低 | 非常低 | 中 |
我个人的经验是：只是应急拿一份代码，用第三方工具最舒坦；目标目录文件特别多，用 SVN 导出最可靠；想长期跟随目标仓库的某个子目录更新，那必须用稀疏检出。这三种方案不冲突，你甚至可以全都掌握，然后看场景灵活切换。
4. 单个文件的下载，别被别人看到的操作蠢哭
4.1 核心逻辑：Raw 链接
下载单个文件，很多人第一反应是点进文件详情页，然后找下载按钮。这个思路不能说错，但效率太低、太不通用。真正的高手都是直接拼 Raw 链接。
GitHub 仓库里的每一个文件，在网页上都有一个对应的“Raw”按钮，点开之后就指向一个直接回源文件的链接。这个链接的格式非常简单，以raw.githubusercontent.com开头。例如：
https://raw.githubusercontent.com/某用户名/某仓库/main/README.md这个链接天然就是可以直接下载的 URL。你在浏览器地址栏里输入它，会直接触发下载；你在终端里用 curl 或者 wget 请求它，也能直接拿到文件内容。非常纯粹、直接，没有任何多余的网页包装。
需要特别强调一点：链接里的main位置是分支名。如果你的目标文件在其他分支上，把main替换成对应分支名就行。有些项目用的默认分支是master或者develop，你拼链接的时候需要去仓库页确认一下，否则会得到 404。
4.2 命令行下载方式：curl 与 wget
在服务器上操作的时候，浏览器那一套就不太好使了，这时候 curl 是最好的伙伴。
curl -L -o 文件名 https://raw.githubusercontent.com/某用户名/某仓库/main/某文件解释一下这里的参数：-L表示跟随重定向，因为某些情况下 GitHub 会临时把请求重定向到 CDN 地址；-o 文件名表示把输出保存成指定文件。如果不加-o，curl 默认会把文件内容直接打印到终端里，碰到二进制文件你就会看到终端乱码，那可真是大型翻车现场。
如果你网络状况不太好，或者想实现断点续传，可以给 curl 加上-C -：
curl -L -C - -o 文件名 https://raw.githubusercontent.com/某用户名/某仓库/main/某文件-C -是“断点续传”开关，如果文件已经下载了一半，再次执行它会自动从上次中断的地方继续。对于下大文件很实用，不过单文件场景用得相对少一些。
如果你是 wget 的忠实用户，对应的命令是这样的：
wget -O 文件名 https://raw.githubusercontent.com/某用户名/某仓库/main/某文件wget 在这类场景下的体验也很不错。而且 wget 天然支持断点续传，只要加-c参数：
wget -c -O 文件名 https://raw.githubusercontent.com/某用户名/某仓库/main/某文件4.3 带 Token 下载私有仓库里的单个文件
很多项目代码托管在私有仓库里，这样 Raw 链接直接访问是会返回 404 的，因为服务器压根不认为你有访问权限。这时候你就需要用到 GitHub 的 Personal Access Token。
首先，你需要在 GitHub 的设置页面里创建一个 token，记得勾选repo权限范围，只有这个范围才允许你访问私有仓库内容。然后在请求头里带上这个 token 即可：
curl -H "Authorization: token 你的Token值" -L -o 文件名 https://raw.githubusercontent.com/某用户名/某私有仓库/main/某文件这里的关键是把 token 放在Authorization请求头里。对于浏览器用户来说，单纯访问私有仓库的 Raw 链接是无法直接下载的，你需要在 GitHub 网页上登录自己的账号，然后通过文件详情页进入 Raw 视图，浏览器会自动附带 Cookie，这样才能下载成功。
这个方法在我日常工作中的使用频率很高，因为很多内部工具和项目配置都是放到私有仓库管理的。有了这一招，写脚本批量拉取多个配置文件时非常方便，不用打开浏览器一个个手动点下载。
4.4 常见误区提醒
单个文件下载看似简单，实际上我看到过不少人在这上面犯糊涂。
第一个误区：有人以为必须先 clone 整个仓库才能拿到里面的单个文件。这是完全错误的，Raw 链接直接从服务器上按路径取文件，根本不涉及 Git 仓库的下载，速度飞快。
第二个误区：有人对raw.githubusercontent.com这个域名不熟悉，会以为这是个钓鱼网站或者第三方链接。其实这就是 GitHub 官方专门用来提供原始文件内容的 CDN 域名，完全是正规的。它的定位就类似于一个文件直链服务。
第三个误区：有人会尝试用 GitHub 的 API 下载文件。虽然从 API 也能拿到文件内容，但它的频率限制比 Raw 链接严格得多，而且返回的数据格式还需要额外处理。对于下载文件这种场景，API 不是最优选择，Raw 链接就是最直接、最省事的。
5. 常见问题与排查技巧实录
5.1 网络超时与连接中断
这个问题在下载完整项目时尤其常见，尤其是大型仓库。前面提到过调大http.postBuffer，但那只解决了 http 协议层面的发送缓冲区问题，如果问题出在整体网络质量上，还有一个更实用的备选方案——使用 SSH 协议代替 HTTPS 协议。
如果你本地配置好了 SSH 密钥对，可以试试换成 SSH 克隆：
git clone git@github.com:某用户名/某仓库.gitSSH 协议走的 22 端口，在某些环境下比 HTTPS 的 443 端口高速更稳定。这没有绝对的好坏，纯粹是实战经验。我的经验是把两种协议都试一下，哪个快就用哪个，很多时候真的能解燃眉之急。
还有一招是设置 Git 的底层传输命令使用git://协议，但现在 GitHub 已经停止对该协议的支持了，这条就别想了。
5.2 浅克隆之后拉取全量历史报错
很多人在使用--depth=1克隆项目之后，过了一阵子想把这个浅克隆的仓库加深成完整仓库，好切换历史版本，却发现操作不顺利。实际上 Git 已经引入了--unshallow参数来解决这个问题，你只需要在仓库目录里执行：
git fetch --unshallow这个命令会拉取所有缺失的历史对象，让浅克隆仓库变回完整仓库。需要注意的是，这个操作消耗的时间和流量等同于一次完整克隆，所以在网络状况不佳的时候要评估好风险再执行。
如果你只是想补充最近几天的历史，而不是全部历史，可以用：
git fetch --depth=100把深度从 1 增加到 100，这样 Git 会拉取最近 100 条提交记录，灵活性更高。
5.3 目录更新后稀疏检出不会自动删除文件
这是一个挺坑的细节。稀疏检出的工作模式决定了，它会对 checkout 的目录做增量同步，但如果你在远程仓库里删除了某个子目录，本地的对应目录并不会自动消失。因为 Git 对“文件被删除”的感知，在稀疏检出模式下是被抑制的。
解决办法是，执行一下git sparse-checkout reapply，它会重新应用稀疏规则，把不该存在的文件清理掉。这个命令我建议在你每次切换分支或者执行完git pull之后，如果发现工作区有多余文件，就顺手执行一下。
5.4 文件名大小写问题导致的下载失败
GitHub 的文件系统底层在 Linux 上运行的，所以它支持同一目录下同时存在readme.md和README.md这样的两个不同文件。但你在本地 Windows 或者 macOS 上使用的时候，文件系统通常对大小写不敏感，在 clone 过程中 Git 就会报错。
我遇到的实际场景是：SVN 导出某个文件夹时，目标文件夹里同时有Docs和docs两个目录，Windows 上直接导致导出失败，提示文件冲突。解决方案是换到 macOS 或者 Linux 环境去执行，或者查看仓库的实际结构，手动排除其中一个目录。这种情况虽然不常见，但一旦碰到就非常恶心，提前了解可以避免莫名其妙卡住。
5.5 一个关于 LFS 大文件的踩坑记录
某些大型仓库使用了 Git LFS（Large File Storage）来管理二进制大文件。这种仓库你单纯使用git clone，表面上只下载了几十 MB 内容，但工作区里的文件却是不可用的指针文件，只有在执行git lfs pull之后才能拿到真正的二进制数据。
也就是说，你操作了完整 clone，拿到了 100 MB 代码，然后发现里面还藏着一个 5 GB 的模型文件需要单独拉取。这个问题很容易在刚接触这类项目时踩坑，白白消耗了时间和流量。我的建议是：在 clone 之前先瞄一眼仓库根目录有没有.lfsconfig或者.gitattributes文件对filter=lfs规则的配置，如果有，要提前做好心理准备，下载体量可能远超想象。
6. 最后分享一点实操心得
这篇文章写到这里，主体内容已经全部讲完了。但按照我的习惯，还是想多分享一点自己在实操里的感受，这可能比那些冷冰冰的命令更能帮助到后来人。
我见过太多人在下载 GitHub 项目时被“完整克隆”这四个字框住了思维。明明只是想弄一个小工具脚本，非要整个仓库 clone 下来，占了半 G 硬盘；明明只是想拿一个配置文件，结果开个浏览器从网页上一层层点击进入，找了半天下载按钮。其实这些操作本可以在一分钟内完成，关键在于你头脑里有没有“按需获取”这个意识。
从我个人的体会来说，Git 这个工具的灵活之处就在于，它并不只有一种用法，而是围绕“传输对象”这个概念衍生出了多种可能性。你完全可以根据自己的实际诉求，选择拉取全部对象、拉取部分路径、或者拉取单个 blob 对象。把这些思路理清了，你会发现 GitHub 下载这件事变得特别简单，也特别快。
另外还有一个小建议：下载代码时顺手把 URL 里的分支写清楚。很多人习惯直接 clone 默认分支，但实际项目的主力分支往往是develop或者release分支，你 clone 完了才发现拿到的代码版本不对，还要再切一次分支，挺浪费时间的。
最后提醒一句：无论用什么方式下载，尽量挑选你真正需要的内容。GitHub 上的仓库越来越多，代码动辄上 GB 的情况并不罕见，学会“精准下载”这一课，能帮你节省大量的时间和磁盘空间。希望这篇内容对你有用，如果你在实操中遇到其他奇怪的报错，也欢迎回来交流，我大概率在踩坑的路上等过你。
