克隆失败首要排查路径、协议、网络三类问题：默认创建同名目录易被忽略；https与ssh地址混用致认证失败；“could not resolve host”多因dns或代理配置异常。
克隆失败时先看 git clone 命令末尾有没有加路径
很多人复制 GitHub 页面上的 git clone https://github.com/user/repo.git 然后直接回车，结果仓库被拉到当前目录下，但没注意它自动建了个 repo 文件夹——你以为“没下载成功”，其实是进错目录了。
- 默认行为：
git clone会用 URL 里最后的仓库名（如repo.git去掉.git）创建同名文件夹，所有文件都在里面 - 想指定本地文件夹名？在命令末尾加上你想要的名字：
git clone https://github.com/user/repo.git my-project - 如果目标文件夹已存在且非空，
git clone会直接报错destination path 'xxx' already exists and is not an empty directory，删掉或换名再试
HTTPS 和 SSH 地址混用会导致认证失败
GitHub 页面右上角点“Code”按钮，默认给的是 HTTPS 地址；但如果你本地配过 SSH 密钥、习惯用 git@github.com:user/repo.git 这种格式，就容易把两种协议地址搞混，导致 push 失败或 clone 时反复要输密码。
- HTTPS 地址（适合快速试用）：
https://github.com/user/repo.git，每次 push 需输账号密码或个人访问令牌（PAT） - SSH 地址（推荐长期使用）：
git@github.com:user/repo.git，需提前运行ssh-keygen并把公钥加到 GitHub 的 SSH Settings 里 - 检查远程地址是否匹配协议：
git remote get-url origin，不对就用git remote set-url origin 新地址换掉
git clone --depth 1 能跳过历史，但后续不能 git pull 到旧提交
只想要最新代码、不关心 commit 历史？用浅克隆确实快，尤其对大仓库。但它本质是“单层快照”，不是完整副本。
-
git clone --depth 1 https://github.com/user/repo.git只下载最近一次 commit 的文件，体积小、速度快 - 但之后运行
git log只能看到一条记录；git checkout切不到历史分支或 tag；git pull默认也只更新这一个深度，没法自动同步更早的提交 - 真需要补全历史？运行
git fetch --unshallow（要求远程支持），或干脆删掉重 clone
遇到 fatal: unable to access 'xxx': Could not resolve host 先查网络和代理
这个错误不是 Git 本身坏了，而是连不上 GitHub 域名。国内用户尤其常见，但很多人第一反应是重装 Git 或换镜像站，其实往往只是本地网络配置卡住了。
- 先试
ping github.com，如果超时，说明 DNS 或网络不通，跟 Git 无关 - 如果你设过 Git 的
http.proxy，而代理已失效，就会卡在这儿：git config --global --unset http.proxy可临时关闭 - 公司/校园网有时会拦截
github.com的 443 端口，换手机热点试试；或者改用 GitHub 官方提供的稀疏域名github.com:443不起作用，得看防火墙策略
