很多人以为git配置就是装个软件、敲两条命令的事但真正用起来才发现坑全藏在细节里。我这次要整理的不是那种泛泛而谈的教程而是一份我自己在重装系统、换新电脑、新入职配置开发环境时反复用到的git配置步骤清单把安装、身份信息、换行符、SSH密钥、与IDE联调、甚至改提交历史这些事全部串起来适合刚接触git的开发者也适合已经用了一段时间但想系统理一遍配置的同学。配置这东西一旦理清逻辑比背命令有用得多。1. 为什么git配置值得从头到尾梳理一遍1.1 这篇记录的来龙去脉我一直有个习惯每次换电脑或者重装系统之后都要重新把开发环境搭一遍。git的配置是其中耗时不多、但最容易出错的环节。表面上看配置git不过就是设置一个用户名和邮箱再生成一把SSH密钥实际使用时却常常冒出一堆问题提交记录上挂的不是自己的名字、Windows下换行符乱跳、IDE里git路径找不到、push的时候要反复输账号密码。这些问题都不算难但确实会打断工作流。所以这次我专门把完整的配置过程记录下来既是给自己日后留一份可操作的清单也顺便分享给需要的人。我想强调的是这份记录不是单纯罗列命令而是把每一步背后的原理和验证方法都写清楚。只有知道为什么这样配置遇到问题时才不至于两眼一抹黑。从工具选型上讲git在开发者工具链里的地位几乎等同于文本编辑器跨平台、免费开源、被所有主流代码托管平台支持。配置这件事本身不复杂但涉及Windows、macOS、Linux三个平台的差异涉及命令行和IDE两套使用习惯还涉及多人协作时对提交规范的要求。把这些维度理清楚配置才算真正到位。1.2 配置层级system、global、local到底配哪个git的配置采用三级结构从低到高分别是system、global、local每一级有独立的配置文件后一级会覆盖前一级的值。初次配置时很多人没搞明白这三个层级结果想改全局配置却只改到了某个仓库的local配置看起来生效了换个仓库又打回原形。system级作用范围是整个操作系统的所有用户配置文件一般在/etc/gitconfigLinux/macOS或C:\Program Files\Git\etc\gitconfigWindows。日常使用很少动这个层级。global级作用范围是当前登录用户的所有git仓库配置文件在用户主目录下Linux/macOS是~/.gitconfigWindows是C:\Users\用户名\.gitconfig。我们常说的“配置git”绝大多数指的就是这个层级。local级作用范围只有当前所在的一个仓库配置文件在该仓库的.git/config里。不同项目需要不同用户名、不同提交人身份时就在这一层配置。查看三层配置总和的命令是git config --list --show-origin它会同时列出所有配置项、配置值以及来自哪个文件。这个命令我每次配置完都会跑一遍用来确认没有漏项、没有冲突。从实际使用的角度讲我个人的习惯是身份类、换行符、编辑器这类通用选项放global只针对某个特定项目的声音放localsystem几乎不动。这样既方便日常命令操作也避免无意间影响系统里其他用户或其他人格化的账号。2. Git安装环境准备决定后面所有配置的起点2.1 Windows、macOS、Linux三个平台的安装方式git的安装本身不难难的是选对方式。Windows下官方给的方案是Git for Windows自带一个Git Bash终端很多新手装上之后只在自带的Git Bash里用git切回系统自带的cmd或PowerShell又发现命令不识别。这其实不是没装好而是安装时“调整PATH环境变量”的选项没有选对。我在Windows上通常用包管理器来装比如winget install --id Git.Git -e --source winget装完把“Git从命令行使用”选成“推荐设置”也就是把git加进系统PATH。如果之前已经装了但没有正确配置PATH可以手动在环境变量里把C:\Program Files\Git\bin加进去。验证方法很简单在任何终端里执行git --version能输出版本号就说明PATH配置正确。macOS上的情况稍微复杂一些。系统自带的git会被Xcode Command Line Tools带出来但版本可能偏旧而且路径和功能不一定符合预期。我更推荐用Homebrew安装brew install git。安装完成后Homebrew会把它自己的路径放在系统路径前面执行which git可以看到实际指向的是Homebrew的路径。这样输出的版本是较新的后续功能也更完整。Linux各发行版的包管理器不一样但核心命令都是一个套路Debian/Ubuntu系用sudo apt install gitRHEL系用sudo dnf install gitArch系用sudo pacman -S git。Linux下装完基本不用管PATH的事因为包管理器会自动处理。需要注意的是有的服务器版系统会内置一个很老版本的git装完之后先看版本太老的话建议找官方源或第三方源升一下版本否则某些新特性比如git switch用不了。从实践的角度来说我不建议在Windows上只靠官网下载安装包一键完成而完全不管安装选项。安装向导里那几项选择不是无意义的设计比如“选择默认编辑器”、“调整PATH环境变量”、“换行符处理方式”每一项目后都会直接影响后续配置。第一次装的时候老老实实把选项看一遍比装完再返工省时间。2.2 安装完成后的自检清单安装完成后不要急着配用户名和邮箱先确认三件事在终端执行git --version确认git可执行文件已经被正确加入PATH。执行git --help确认帮助文档正常输出这一步可以间接验证安装没有损坏。执行git config --list查看当前是否已经存在历史配置。了解已有的配置项才能避免新配置和旧配置互相冲突。这三点都通过之后再进入全局配置环节。现实中很多人装完直接跳过验证等到IDE里提示找不到git才回头折腾不如一开始就把地基打牢。3. 身份信息与换行符全局配置的两件大事3.1 用户名和邮箱一句话背后的事配置身份信息是git初始化之后第一个要做的操作命令是git config --global user.name Your Name git config --global user.email your_emailexample.com这两个配置项看似简单背后却隐藏着几个容易忽视的问题。第一git在提交时会把用户名和邮箱写入commit对象这个信息一旦提交就很难彻底抹掉。如果配错邮箱以后代码审查时别人看到的提交人就是一个不存在的身份追溯起来非常麻烦。第二如果第一次提交前没有配置身份信息git会报一个非常经典的错误Please tell me who you are并提示你运行上面的两条命令。第三如果公司和私人项目都在同一台电脑上用不应该把公司邮箱写进global配置里因为这样会把公司身份泄露到私人项目。正确的做法是global里配置个人身份公司的仓库目录下用local配置覆盖成公司身份。验证身份配置是否生效可以执行git config --global --get user.name和git config --global --get user.email。如果看到输出值就是你设置的内容说明配置已经生效。我还会额外执行git config --list整体扫一眼确认没有其他历史残留的配置项影响身份识别。3.2 换行符跨平台协作最容易踩的暗坑换行符的问题是在跨平台团队协作时最容易浮现的。Unix/Linux/macOS平台默认使用LF换行符Windows默认使用CRLF回车换行。git在设计时允许通过core.autocrlf这个选项来控制提交到仓库时和检出到工作区时换行符的转换方式。Windows上的推荐设置是git config --global core.autocrlf true这样做的效果是提交时自动把CRLF转换为LF存储到仓库检出时自动把LF转换为CRLF写到本地。macOS/Linux上的推荐设置是git config --global core.autocrlf input这里input的含义是提交时把CRLF转换为LF但检出时不进行反向转换保持仓库里的LF原样。我在实际项目中遇到过一种情况有人把core.autocrlf配置成了false于是仓库里混入了大量CRLF行尾每次打开diff都看到整文件被标红代码审查体验非常差。这个问题没有技术上的难度但排查起来很耗时间因为它的根源不在某个具体代码而在所有人的本地配置差异。所以我的建议是配置完成后团队成员统一约定使用相同策略Windows使用truemacOS/Linux使用input避免配置漂移。如果仓库里已经存在换行符混乱问题可以使用git add --renormalize .重新规范化文件换行。3.3 其他值得顺手配好的全局项除了身份和换行符以下全局配置项我也会一并配好。每个项都有明确的用途如果不配后续使用中一定会在某个瞬间被卡一下。默认编辑器配置git config --global core.editor code --wait这条命令把git默认编辑器设置为VS Code并等待文件关闭后才继续执行后续操作。git会在很多场景调用编辑器比如写提交信息、执行git rebase -i时打开交互编辑页面。如果不配置会调用系统默认编辑器在Windows上通常是难用至极的vim对不熟悉vim的人来说几乎等于卡死。默认分支名配置git config --global init.defaultBranch main从2020年底开始各大托管平台相继把新建仓库的默认分支名从master改成了main。但本地执行git init时老版本git仍然会默认创建master分支。全局配置这一项之后新建仓库的默认分支名就跟平台保持一致省去每次手动改名的动作。pull行为配置git config --global pull.rebase false这个配置的含义是执行git pull时默认使用merge方式合并远端分支而不是rebase方式。两种方式各有适用场景但对我个人来说merge方式产生历史更直观适合大多数日常协作场景。如果你习惯用rebase整理历史也可以改成true但不要不配置就裸跑git pull不同git版本默认行为不一致容易产生意外结果。一些可选的便捷配置git config --global color.ui true git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.cm commitcolor.ui让git输出带颜色肉眼区分改动区域更轻松。别名配置则是把高频命令缩成更短的版本比如git st代替git status。这些配置纯粹是个人习惯有需要的就配没需要的可以跳过。4. SSH密钥告别每次输入账号密码的推送体验4.1 SSH和HTTPS怎么选使用git操作代码托管平台时远程地址有两种协议HTTPS和SSH。HTTPS协议下如果你没有配置凭据管理器每次push都要输入用户名和密码或访问令牌SSH协议下本机生成密钥对公钥放到托管平台私钥留在本地push和pull时自动完成身份认证。从便利性和安全性两个维度看SSH都是更推荐的选择。第一个原因是认证方式更干净不用反复输入密码也不用折腾token有效期的问题第二个原因是SSH密钥本身是一种较强的身份凭证配合适当的权限设置比反复传输密码更安全。我不能替所有人下结论说HTTPS完全不可用。有些场合下HTTPS确实有优势比如临时在一台不常使用的机器上clone仓库用HTTPS加一次性令牌比配置SSH密钥快得多。但日常开发的主力环境我强烈建议配好SSH。4.2 生成密钥的四个步骤第一步检查是否已有密钥ls -al ~/.ssh如果目录里存在id_ed25519和id_ed25519.pub说明你之前已经生成过密钥。如果你不记得这个密钥是否被使用过最好不要随意覆盖。可以新增一把独立密钥也可以复用原来的。第二步生成新密钥ssh-keygen -t ed25519 -C your_emailexample.com这里-t ed25519指定密钥类型为ED25519相比传统的RSAED25519密钥更短、生成速度快、安全性更强目前主流平台都已支持。如果某些老旧的内部平台不支持ED25519退回RSA时使用ssh-keygen -t rsa -b 4096 -C your_emailexample.com。-C后面的内容只是注释通常填邮箱方便你日后识别这把密钥属于哪个设备或什么用途。执行命令后终端会询问保存位置和passphrase。保存位置直接回车使用默认路径~/.ssh/id_ed25519即可。passphrase可以理解为私钥的解锁密码我建议在个人主力电脑上留空直接回车因为设置passphrase之后每次使用SSH连接都可能要输入一次密码非常影响效率。但在安全性要求更高的环境里passphrase还是值得设置的。第三步把公钥添加到托管平台。先查看公钥内容cat ~/.ssh/id_ed25519.pub复制输出的完整内容登录代码托管平台在个人设置里的SSH密钥页面粘贴保存。不同平台的菜单位置略有差异但基本都在“设置/SSH Keys”下。第四步验证连接ssh -T gitgithub.com以GitHub举例首次验证会提示确认服务器指纹输入yes即可。如果看到Hi xxx! Youve successfully authenticated之类的输出说明SSH密钥配置成功。4.3 多平台、多账号的密钥管理一个常见场景是同时使用GitHub、GitLab和公司内部的代码托管平台。如果每个平台都使用同一把密钥也可以正常工作但一旦某把私钥泄露所有平台的账号都有风险。更推荐的做法是每个平台生成一把独立密钥。在~/.ssh/config文件里可以配置不同域名的认证规则。例如Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github Host gitlab.com HostName gitlab.com User git IdentityFile ~/.ssh/id_ed25519_gitlab配置完成后连接gitgithub.com时git会自动选择id_ed25519_github这把密钥连接gitgitlab.com时选择id_ed25519_gitlab。这样每个域名的身份是隔离的某一把密钥泄露不会波及其他平台。另一个场景是一台电脑上同时存在个人账号和公司账号且两个账号用的是同一家托管平台。这种情况下config里的匹配条件可以改为使用Host别名区分Host github-work HostName github.com User git IdentityFile ~/.ssh/id_ed25519_work Host github-personal HostName github.com User git IdentityFile ~/.ssh/id_ed25519_personal克隆仓库时把远程地址从gitgithub.com:组织名/仓库名.git改为gitgithub-work:组织名/仓库名.gitgit就会使用对应的密钥进行认证。这种做法的好处是同一个平台下两个账号完全可以共存互不影响。在配置SSH密钥的过程中有几个细节值得特别注意。第一公钥文件是id_ed25519.pub不是id_ed25519后者是私钥绝不能泄露、不能上传、不能分享给任何人。第二~/.ssh目录的权限在Linux/macOS下需要收紧一般建议执行chmod 700 ~/.ssh和chmod 600 ~/.ssh/id_ed25519否则ssh可能因为权限过宽而拒绝使用该密钥。第三验证连接时如果报Permission denied (publickey)大概率是公钥没有加到平台或者本地私钥路径没有被正确选择按ssh -vT输出逐行排查即可。5. 与IDE和常用工具链的配合5.1 从终端到IDEGit路径要理顺git配置好之后下一步是让IDE识别git。以PyCharm和VS Code这两个主流编辑器为例它们都内置了git集成但底层调用的还是命令行里的git可执行文件。IDE找不到git通常是因为git没有被加入PATH或者IDE设置里指向了一个不存在的路径。Windows下如果IDE报错说找不到git先在设置里找到Version Control/Git相关选项手动把git可执行文件路径填成C:\Program Files\Git\bin\git.exe。macOS下一般是/usr/local/bin/git或/opt/homebrew/bin/git取决于Homebrew安装路径。Linux下可以用which git查看具体路径。配置好路径之后IDE里的git面板才能正常显示分支、提交、diff这些信息。这一步还有一个容易被忽略的连带效果IDE的终端和IDE的git操作共用同一个SSH配置所以只要终端里SSH验证通过IDE里推送代码也不需要额外输密码。理论上讲这个环节最怕的就是把路径配错。配错的表现是IDE里显示git命令不可用但终端里一切正常。如果你也遇到这种情况先检查IDE的git路径设置别急着重装git。5.2 conda环境下命令找不到git的处理Python开发里使用conda管理环境是非常常见的做法。有时在conda的某个虚拟环境激活后终端会提示git: command not found这通常是PATH优先级的问题不是git真的丢了。conda激活环境时会把虚拟环境的bin目录Windows下是Scripts目录插到PATH最前面。如果虚拟环境里没有安装git而系统git所在的目录又被虚拟环境前缀挡住终端就会找不到git。解决办法有两个方向。第一个方向是在终端里使用git的绝对路径例如Windows下C:\Program Files\Git\bin\git.exemacOS/Linux下用which git查到的路径。这种方法治标不治本每次都要敲一长串路径。第二个方向是在需要长期使用git的conda环境里直接安装git例如conda install -c conda-forge git。这样激活该环境后git就在虚拟环境的PATH里。我的推荐倾向是第二种。因为conda环境本来就是为项目隔离设计的在环境里依赖什么就装什么避免依赖宿主系统的可执行文件。不过要注意为了环境之间一致性和稳定性不要在太多环境里重复安装git使用频率高的环境装好就够。5.3 常用命令速查表git的命令体系庞大但日常工作真正高频使用的命令就那么十几条。我把它们按使用顺序整理成一张表方便配置完成后快速上手。场景命令说明克隆仓库git clone url把远程仓库完整复制到本地查看状态git status查看工作区、暂存区、HEAD三者差异添加改动git add file或git add .把文件改动加入暂存区提交改动git commit -m message把暂存区内容记录为一次提交推送到远端git push把本地提交上传到远程仓库拉取远端git pull把远程仓库更新合并到本地查看历史git log --oneline以简洁模式查看提交历史创建分支git branch name或git switch -c name创建并切换到新分支切换分支git switch name或git checkout name切换已有分支合并分支git merge branch把指定分支合并到当前分支查看差异git diff查看工作区与暂存区的差异暂存改动git stash把未提交改动临时存入栈中恢复暂存git stash pop把暂存的改动恢复出来这张表并不是让新手背下来而是提供一个查询入口。实际工作中遇到不熟悉的操作时先git status再根据提示选择下一步比硬背命令高效很多。git的提示信息已经做得很人性化比如未提交的改动它会提示你该用git add还是git commit。6. 修改提交历史的三个工具amend、rebase、reset6.1 git commit --amend改最近一条提交git commit --amend是git里被讨论最多、也最容易被误用的命令之一。它的作用是修改最近一次的提交。常见的使用场景有三个提交信息写错了想改字、上次提交漏了文件想补进去、或者刚提交完发现还有一处小改动想并入上一条提交而不是新建一条。基本用法git commit --amend -m 新的提交信息如果只想修改提交信息直接带上-m写新信息即可。提交完之后最近一条提交的message会被替换成新内容。如果想补充文件先把遗漏的文件加入暂存区再执行git add 遗漏的文件 git commit --amend --no-edit--no-edit表示不打开编辑器修改提交信息保留原来的message只是把暂存区的改动并入上一条提交。执行git commit --amend时git会为这个提交生成新的commit哈希值。这带来一个非常重要的后果如果这条提交已经推送到了远程仓库直接git push会报错因为远端历史已经被修改。这种情况下需要强制推送git push --force。但强制推送会覆盖远程分支历史如果这个分支是共享分支其他同事的本地历史就会错乱。我使用--amend的经验可以浓缩成一句话没推送到远端的提交放心改已推送的提交要三思。尤其在公司团队仓库里强制推送共享分支属于高危操作能不做就不做。如果确实需要修改已经推送的历史优先和团队同步确认没有其他人在该分支上工作再执行强制推送。6.2 git rebase -i整理一批提交当需要修改的不只是最近一条提交而是连续的一段提交时就要用到git rebase -i。它允许你交互式地编辑提交列表对每个提交执行pick、reword、edit、squash、fixup等操作。用法示例git rebase -i HEAD~3命令执行后git会打开一个交互编辑界面列出最近3条提交pick 3c2a1e2 提交信息A pick 5b8f6d1 提交信息B pick 9a0c4e7 提交信息C把第二、第三条的pick改成squash或缩写s保存退出git会把提交B和C合并进提交A并打开编辑器让你填写合并后的提交信息。fixup类似squash区别是fixup会直接丢弃被合并提交的信息用第一条提交的信息作为合并结果。git rebase -i的核心价值在于整理提交历史让最终push到远程的分支看起来逻辑清晰。比如开发过程中产生了“临时调试”“修复拼写错误”“移除无用测试代码”这类噪音提交用squash合并成一条干净的提交后代码审查的压力会小很多。但这恰恰是rebase风险最大的地方。-i参数会重写提交哈希凡是rebase涉及到的提交全部会生成新的哈希值。如果已经推送过这些提交同样需要强制推送。我的做法是功能分支在完成联调、准备提PR之前用git rebase -i整理一遍提了PR并且别人已经review过的提交不再使用rebase改写。这个习惯可以最大程度减少协作中的历史冲突。6.3 reset与revert回退的两个方向回退操作同样存在两个方向git reset和git revert它们的区别很容易被忽视。git reset是把分支指针回退到某个历史提交同时可以选择是否保留工作区改动。常见用法git reset --soft HEAD~1 git reset --mixed HEAD~1 git reset --hard HEAD~1--soft回退提交保留暂存区和工作区改动。--mixed默认回退提交和暂存区但保留工作区改动。--hard丢弃所有改动完全回到指定提交的状态。--hard是最危险的操作一旦执行未提交的工作区改动会丢失且无法用普通方式找回。我曾见过同事执行git reset --hard之后发现自己的未提交代码全部消失只能靠IDE的本地历史才恢复部分文件。所以我在执行--hard之前一定会先跑git status确认没有未提交的改动或者先git stash暂存。git revert的思路完全不同。它不是把分支指针移回过去而是生成一个新的反向提交来抵消指定提交的改动。执行git revert 提交哈希git会计算该提交相对父提交的差异反过来应用一次生成一条新提交记录。这个操作不会改变已有历史因此可以安全地推送到远程不会影响其他协作者的提交。日常开发的判断原则是改动还没推送用git reset改动已经推送且可能被别人拉取用git revert。当然也没必要把这两个操作看成互斥。清理本地混乱的历史时常用reset撤销一个已经上线的问题提交时revert是唯一推荐方案。7. 常见问题排查与配置校验7.1 我实际踩过的坑和解决过程配置git这么多年我积累了不少“教科书里不会写”的坑。挑几个典型的说说。第一个坑是Windows的换行符问题。最早我用core.autocrlf true配置全局但公司某个老仓库里本身存的是CRLFclone下来后diff变得异常混乱。排查了很久才发现是仓库历史残留的换行符和新配置叠加的结果。最终通过git add --renormalize .重新规范化并约定团队统一配置问题才彻底解决。这个坑的教训是换行符配置不仅要自己配还要保证所有人配置一致。第二个坑是SSH密钥权限。在Linux服务器上配好密钥之后发现ssh -T gitgithub.com始终报Permission denied检查公钥也确认添加到了平台。后来用ls -la ~/.ssh发现私钥文件的权限是644ssh直接拒绝使用“世界可读”的私钥。把权限改成600之后问题立刻解决。这类问题在Windows的Git Bash里相对少见因为NTFS权限模型不同但macOS和Linux下必须留意。第三个坑是git commit没配身份信息时报错。第一次往GitHub上传代码时直接提交就遇到Please tell me who you are。其实报错信息已经写得很清楚但很多新手看到英文报错就慌实际上只要执行两条git config --global命令就好。这个坑也说明配置身份信息应该是安装之后立即做的事不要等到提交时才想起来。第四个坑是conda环境里找不到git。刚转用conda时激活环境之后执行git status直接报command not found吓得我以为git被环境搞坏了。后来才知道是PATH优先级的问题。我最终在常用的conda环境里直接conda install git一劳永逸。这个经历也让我养成了一个习惯排查环境问题时先分清是软件缺失还是PATH问题再看该怎么办。7.2 快速排查速查表把上面踩过的和别人问过的高频问题整理成一张速查表遇到问题可以直接对照定位。问题现象可能原因解决办法git: command not foundgit未安装或未加入PATH安装git检查PATH环境变量push/pull需要反复输账号密码使用HTTPS协议且未配置凭据管理改用SSH协议并配置SSH密钥Permission denied (publickey)SSH公钥未添加或私钥路径不对检查公钥是否在平台设置中检查~/.ssh/config提交报Please tell me who you are未配置用户名和邮箱执行git config --global user.name/user.emaildiff里出现大量整段标红疑似换行符变动换行符配置不一致统一core.autocrlf必要时git add --renormalize .强制推送后同事本地历史错乱push --force覆盖了共享分支避免对共享分支强制推送只在功能分支使用中文文件名显示成数字转义core.quotepath默认行为git config --global core.quotepath false提交后commit信息打错字提交信息错误未推送时用git commit --amend -m修改这些问题的根源大多集中在配置项缺漏、协议选择不当或历史操作互相冲突。出现报错时先冷静看提示信息git的提示绝大多数情况下已经告诉了你下一步该做什么。真正需要担心的反而是那些不报错但行为异常的情况比如分支历史突然多个合并节点、push时提示非快进更新这时候再回看配置和工作流设计。7.3 配置完成后怎么自检每次配置完一轮git环境我习惯按下面几步检查确认整个链路是通的。这套自检流程不复杂但很管用。首先验证安装和身份git --version git config --global --get user.name git config --global --get user.email其次验证SSH链路ssh -T gitgithub.com然后找一个真实仓库验证完整流程。没有现成仓库的话可以临时建一个测试目录mkdir git-test cd git-test git init echo hello readme.md git add readme.md git commit -m init git log --oneline最后在IDE里打开这个测试目录确认IDE的git面板能识别分支、能展示改动尝试执行一次提交和推送。如果IDE的git面板能正常工作说明git的可执行文件路径、用户配置、SSH认证全部打通。全部通过之后这份配置就算真正完成了。剩下的就是日常使用中慢慢积累命令熟练度和工作流经验。最后分享一个我自己的小习惯配置文件里的每个global项我都会在旁边的注释里写清楚为什么这么配。比如换行符为了兼容团队、默认分支名为了跟平台一致、pull.rebase为了历史清晰。日后看着注释就不需要回忆当时的选择也方便在换机器时复用同一套决策逻辑。