HTTP、浏览器、跨域与Git：前端联调排错实战指南

从第11天到第15天，我把HTTP、浏览器、跨域和Git这四个主题集中放在一起学习。这四个模块看起来像是各自独立的“知识点”，但真正学完才发现，它们其实是同一条完整链路：HTTP是浏览器和服务器之间的通信协议，浏览器是前端代码唯一真正运行的场所，跨域是前后端联调时必踩的一道坎，Git则承载了整个协作开发过程。把这四块连起来理解，前端日常报错的排查思路基本就通了一半。这篇总结就按这个顺序展开，每一块我都会带上实际调试中遇到的坑和解决办法。

学习这段时间的动机其实很简单：前面十天的内容一直停留在“写页面、写交互”的层面，可一旦进入真实项目，接口联调、发布排查、多人协作，哪一样都绕不开这几个主题。尤其是跨域和Git这两块，几乎每个新人都栽过跟头。所以这五天我特意把重心放在“理解原理”和“动手复现”上，而不是只背面试题。下面进入正题。

1. HTTP协议：搞清楚浏览器和服务器之间到底怎么说话

1.1 先从报文结构看起，别再把请求和响应当黑盒

HTTP协议说白了就是一套“明文规则”：客户端发送一个请求报文，服务端处理完返回一个响应报文，两者都遵循基本固定的结构。请求报文由请求行、请求头部、空行和请求体组成，响应报文则由状态行、响应头部、空行和响应体组成。实际调试时，打开浏览器DevTools的Network面板，随便点开一个请求，看到的Raw Headers就是这个东西。

举个例子，一个登录接口的真实请求报文长这样：

POST /api/login HTTP/1.1 Host: example.com Content-Type: application/json User-Agent: Mozilla/5.0 Cookie: session=abc123 Content-Length: 25 {"username":"tony","password":"****"}

其中第一行的POST是请求方法，/api/login是路径，HTTP/1.1是协议版本。头部里比较关键的几个字段：Content-Type决定了请求体怎么被解析，Cookie负责携带会话标识，Origin/Referer在后面讲跨域时会频繁出现。请求体如果是JSON格式，后端一般靠Content-Type: application/json来区分，如果漏了这个头，很多框架会把请求体当作表单解析，拿到的数据就是空的。

响应报文的骨架类似，区别是状态行变成了状态码加原因短语，比如HTTP/1.1 200 OK。整个报文结构不需要死记硬背，但一定要做到“看到Network里的请求，能迅速对应到这几个部分”，因为后面所有的缓存、跨域、鉴权问题，最终都要落到某个具体字段上。

GET和POST是面试里被问烂的问题，但很多人的理解其实有偏差。最准确的说法是：HTTP方法只是语义约定，真正执行逻辑的是服务端代码。GET设计为幂等、可被缓存、参数放URL；POST设计为非幂等、参数放Body。但在实际项目里，只要你后端接口约定好，GET带Body也能被某些服务器处理，POST也可以被设计成幂等，所以不要死磕“GET一定比POST安全”这种伪命题。前端真正要注意的是：不要用GET提交敏感数据，URL会留在历史记录和日志里；不要用GET请求做删除、修改这类操作，容易被预取或爬虫触发，这也是RESTful规范存在的意义。

1.2 状态码排查速查：前后端联调80%的问题靠它定位

状态码是我学HTTP入门后收益最大的一块。之前遇到接口报错只知道“请求失败了”，现在看一眼状态码，基本能判断问题出在前端还是后端，该去找谁。我整理了一张自己常用的速查表：

状态码	含义	前端排查方向
200	成功	检查响应体是否符合预期
204	成功但无内容	DELETE/PUT常见，前端无需解析Body
301 / 302	永久/临时重定向	检查请求地址是否需要跟随跳转
304	协商缓存命中	文件未修改，浏览器用本地缓存
400	请求语法错误	检查参数格式、字段名、Content-Type
401	未认证	登录态失效，跳登录或刷新Token
403	无权限	已登录但权限不够，提示用户
404	资源不存在	检查URL路径、接口是否部署
500	服务端内部错误	找后端看日志，多半是代码异常
502	网关收到无效响应	服务可能崩溃或未启动
504	网关超时	后端接口处理过慢，检查慢查询

我在真实项目里遇到过最典型的一次：前端请求一个列表接口，返回401，但用户明明刚登录过。排查后发现是后端改了Token过期时间，前端拦截器只处理了500和网络错误，没处理401，导致用户卡在一个假“已登录”状态。后来加了统一的响应拦截，发现401就跳登录页并清除本地存储，这个问题才算彻底解决。

还有个小经验：403和401千万别混为一谈。403是“服务器认识你，但你没有权限做这件事”，401是“服务器根本不知道你是谁”。有的团队会把错误提示语写反，用户看到“请先登录”但实际上已经登录了，这类型低级错误排查起来非常消耗时间。

1.3 HTTPS、缓存与连接复用：页面加载速度的隐形质量门

学完基础报文后，我专门花了一天集中看HTTPS和缓存。HTTPS本质是HTTP外面套了一层TLS/SSL加密隧道。握手过程可以通俗理解为“两个人第一次见面先互亮证件，再协商一个临时暗号，后续所有对话都用暗号加密传输”。实际配置是后端的事，但前端要明白三件事：明文HTTP容易被抓包篡改，所以涉及登录、支付等敏感场景必须HTTPS；HTTPS握手有额外开销，所以连接复用和缓存策略对性能影响很大；证书过期或域名不匹配时浏览器会直接拦截，用户看到“您的连接不是私密连接”时，大概率不是前端代码问题。

HTTP缓存这块，是“通过版本号变更，让前端强制刷新页面”这个需求的理论根基。浏览器缓存分为强缓存和协商缓存两类。强缓存命中后浏览器根本不会发请求，直接使用本地副本，由Cache-Control（比如max-age=3600）控制；协商缓存会发一个带条件的请求，服务器根据ETag或Last-Modified判断文件是否变化，没变就返回304，让浏览器继续用本地缓存。

实际项目里我们通常这么做：index.html设置成Cache-Control: no-cache，确保用户每次打开都能拿到最新入口文件；而带内容指纹的资源文件，比如app.a1b2c3.js，则设置一年强缓存。因为文件名里的hash是根据内容计算的，内容变了文件名自然变，浏览器会当成新文件去请求。这样既保证了更新后用户能刷到新版本，又让未变化的静态资源能充分利用缓存。我见过很多团队上线后用户还在用旧页面，多数情况就是HTML被强缓存了，或者静态资源没有加指纹。

连接复用也值得单独说。HTTP/1.1默认支持Connection: keep-alive，同一个TCP连接可以连续发送多个请求，省去反复握手的开销。但浏览器对同一域名下的并发连接数是有限制的，Chrome大概限制在6个左右。这意味着一个页面同时发很多请求时，后面的请求得排队。HTTP/2则彻底解决了这个问题，它在一个连接上通过多路复用同时并行多个请求，还引入了头部压缩。现在的实践是：nginx开启HTTP/2，静态资源走带指纹的强缓存，接口服务保持长连接参数合理设置，这样页面加载速度会有明显提升。

2. 浏览器机制：从输入URL到页面可交互，中间到底发生了什么

2.1 渲染管线：HTML、CSS、JS是怎么变成像素的

浏览器拿到HTML后，会做一套流水线处理：构建DOM树、构建CSSOM树、合成渲染树、计算布局、绘制、合成。这个过程看起来简单，但里面藏着不少性能优化的关键点。CSS样式表会阻塞渲染，因为浏览器必须等CSSOM构建完成才知道页面该长什么样；而普通script标签会阻塞DOM解析，因为浏览器不知道脚本里会不会用document.write改写页面。这也是为什么前端规范一直强调“CSS放头部，JS放底部”或者给script加defer/async。

实际调试时，想看到底哪个文件拖慢了首屏，可以用DevTools的Performance面板录制一次加载过程，里面能直接看到DOMContentLoaded和Load事件的时间点，以及每个资源的加载耗时。我之前做过一次优化，发现页面首屏慢的原因是某个第三方统计脚本是普通script加载的，阻塞了DOM解析，后来给它加上async后首屏速度提升很明显。

这里要养成一个条件反射：涉及到修改页面宽高、位置、隐藏显示的操作，浏览器会触发重排和重绘；只改颜色、背景、阴影这类不影响布局的属性，浏览器会跳过重排，直接重绘。重排的开销远大于重绘，所以批量操作DOM时，尽量用class切换把多次布局变化合并成一次，或者用requestAnimationFrame把操作聚集到下一帧。js框架兴起后，很多人不用再手写这些优化了，但理解底层还是很有必要，毕竟排查性能问题时，判断“是不是频繁操作DOM导致卡顿”是一个基本思路。

2.2 事件循环：setTimeout为什么总是“不准时”

JavaScript是单线程的，同一时间只能执行一段代码，异步都得靠事件循环来调度。理解事件循环的关键是分清宏任务和微任务：宏任务包括整个script、setTimeout、setInterval、I/O事件；微任务包括Promise.then、MutationObserver、queueMicrotask。每一轮事件循环，先执行完当前宏任务，再把宏任务执行过程中产生的所有微任务全部清空，最后进行渲染或进入下一轮宏任务。

我用这段代码给团队讲过很多次事件循环：

console.log('1'); setTimeout(() => { console.log('2'); }, 0); Promise.resolve().then(() => { console.log('3'); }); console.log('4');

最终输出顺序是1 4 3 2。很多新人理所当然认为setTimeout是0毫秒就该先执行，但实际它被放到了宏任务队列，要等到当前同步代码和微任务全部跑完才轮到。所以setTimeout(fn, 0)并不意味着立即执行，它只是把fn排到下一轮宏任务的队首。如果前面有大量微任务，它依然会被拖得很晚。

这个机制也解释了为什么前端不能把状态更新完全寄托在性能上：React的setState批量更新，本质上就是利用微任务/同步调度来合并更新，减少重复渲染。理解事件循环还有一个实操点：当页面出现“点击按钮后界面很久才更新”的情况，不要急着怀疑框架，先用Performance看看主线程上有没有长任务（Long Task）在阻塞，找出那些耗时超过50ms的同步脚本，它们就是卡顿的元凶。

2.3 存储与安全：Cookie、localStorage和XSS/CSRF的攻防

浏览器的本地存储方案有好几种，我曾经在项目里见过把所有用户信息一股脑塞进localStorage的做法，后来因为XSS漏洞差点出事，才意识到存储方案选型要跟安全一起考虑。这里整理一个对比：

存储方案	容量	生命周期	请求自动携带	适用场景
Cookie	约4KB	可设置过期时间	是	会话标识、登录态
localStorage	约5MB	持久保存，除非手动清除	否	非敏感业务数据
sessionStorage	约5MB	标签页关闭即失效	否	临时页面状态
IndexedDB	更大	持久保存	否	结构化大数据、离线缓存

Cookie的问题在于它每次请求都会自动带上，一旦被恶意脚本读取，登录态就泄露了。所以设置Cookie时一定加上HttpOnly，让JS读不到；还要善用SameSite属性，限制第三方网站发起的跨站请求携带Cookie，这是防御CSRF的重要一环。CSRF的攻击方式是：你登录了银行A，又在恶意网站B点了某个隐藏表单请求，B借你浏览器里自动携带的A站Cookie，伪造一次转账请求。防御手段除了上面说的Cookie属性，还有CSRF Token、校验Referer等，这些在前后端分离项目里尤其要重视。

相比之下，localStorage容量大但纯靠JS读写，一旦页面被注入恶意脚本，所有数据都可能被拖走。所以只建议放一些不敏感的数据，比如主题配置、用户昵称之类；Token等敏感信息要么放HttpOnly Cookie，要么和后端商量好存储策略。XSS的防御是前端安全的核心：用户输入内容输出到页面时一定要转义，<script>、<img onerror>这类标签必须被过滤；再配合内容安全策略CSP，限制外部脚本加载，整个防御体系才算完整。很多人学浏览器安全只想背面试题，其实真正到项目里，一个未转义的用户评论就能把整站拖垮，这个代价我亲眼见过。

IDE内置浏览器调试也算浏览器机制的一个延伸应用。像HBuilderX这类工具内置了调试浏览器，本质上是集成了Chromium内核和调试协议。用它debug时，注意确认内置浏览器的版本，和线上用户使用的浏览器内核可能存在差异，某些CSS行为未必一致，所以本地调试可以依赖IDE，但最终上线前一定要用真实Chrome或目标用户群体的浏览器多测几遍。

3. 跨域问题：同源策略与前端调试的实战解法

3.1 先搞清楚什么是“源”，再理解为什么浏览器要拦你

跨域这个现象，本质上源于浏览器的同源策略。所谓同源，需要协议、域名、端口三者都相同。随便举几个例子：http://example.com和https://example.com不同源，因为协议不同；https://example.com和https://www.example.com不同源，因为域名子域不同；https://example.com:8080和https://example.com:443不同源，因为端口不同。

为什么要有这个策略？因为浏览器要保护用户的数据安全。如果没有同源限制，你打开任意一个恶意网站，它都能用脚本去请求你银行网站的数据，那整个互联网信用体系就崩了。所以浏览器默认不允许一个源去读取另一个源的响应内容。

这里有个特别重要的认知：跨域限制拦截的是浏览器的响应，而不是请求本身。也就是说，浏览器把请求发出去了，服务器也处理了并返回了数据，只是浏览器出于安全策略，把这个响应拦下来不给JS读取。开发控制台报“CORS error”时，请求在Network面板里其实能看到，状态可能还是200，只是JS拿不到数据。理解了这一点，就知道“前端改一行配置解决跨域”为什么往往是伪命题——真正需要开口的是后端或者网关。

实际联调中，本地开发最常见的跨域场景就是前端跑在localhost:8080，后端接口在api.example.com，打开页面一请求就被拦。网上很多教程让人装个Chrome插件关掉同源策略，我强烈不建议这么干，关闭安全策略相当于裸奔，一旦忘了关闭，随便一个网页都能读你当前网站的敏感数据。正确做法是走下面的CORS、代理或Fiddler调试方案。

3.2 CORS：让服务端明确表态“我允许你跨域”

CORS是跨域的主流解决方案，核心逻辑就一句话：服务器在响应头里明确告诉浏览器“我允许你这个源来读我的数据”。关键响应头是Access-Control-Allow-Origin，前端不需要特殊改动，后端配置好就能正常请求。

但实际项目里CORS的坑特别多。最简单的配置是Access-Control-Allow-Origin: *，表示允许任意源访问，但一旦涉及Cookie或自定义头，这个通配符就不能用了，必须写成具体的源，例如Access-Control-Allow-Origin: https://example.com，同时还要加上Access-Control-Allow-Credentials: true。前端如果使用fetch或XMLHttpRequest，还要设置credentials: 'include'或withCredentials = true。两边忘设置任何一个，都会出现“虽然后端允许了，但浏览器依然报跨域错误”的情况。

还有一个很容易踩的坑是预检请求。当请求不是简单请求时，比如使用了自定义Header、Content-Type为application/json、或者用了DELETE/PUT方法，浏览器会先发一个OPTIONS预检请求，询问服务器允不允许这个方法、允许哪些头。预检请求经常出问题的地方在于：后端路由没有处理OPTIONS方法，导致预检请求返回404或405，浏览器就不发真实请求了，前端会误以为“接口挂了”。排查办法是打开Network面板，看有没有一个类型为OPTIONS的请求，看它的响应状态和头字段是否正常。

我一般在Node后端会用类似这样的中间件统一处理CORS：

app.use((req, res, next) => { res.setHeader('Access-Control-Allow-Origin', 'https://your-frontend.com'); res.setHeader('Access-Control-Allow-Methods', 'GET,POST,PUT,DELETE,OPTIONS'); res.setHeader('Access-Control-Allow-Headers', 'Content-Type,Authorization'); res.setHeader('Access-Control-Allow-Credentials', 'true'); if (req.method === 'OPTIONS') { return res.sendStatus(204); } next(); });

生产环境的跨域不应该每个服务各配一遍，那样太乱了。我建议通过统一的API网关或者nginx在入口层处理，只维护一份CORS规则。nginx的配置大概是add_header Access-Control-Allow-Origin $http_origin;配合add_header Access-Control-Allow-Credentials true;，注意$http_origin变量能拿到请求方源，避免硬编码。整体思路就是：跨域规则入口统一治理，业务服务不重复处理。

3.3 JSONP与iframe：老方案没死，特定场景依然好用

CORS虽然好用，但有些接口是老系统，后端改不了，或者服务端不支持OPTIONS预检，这时候就轮到JSONP出场。JSONP的原理极其简单：script标签不受同源策略约束，可以加载任意域的脚本，那就动态创建script标签，把回调函数名告诉服务器，服务器把数据包进callback({...})的调用里返回，前端拿到后执行回调。

实际代码大概长这样：

function jsonp(url, callbackName, callback) { const script = document.createElement('script'); script.src = `${url}?callback=${callbackName}`; window[callbackName] = callback; document.body.appendChild(script); } jsonp('https://api.example.com/data', 'myCallback', (data) => { console.log('拿到数据', data); });

JSONP的局限也很明显：只能GET请求，没有统一的错误处理，请求失败时无法感知，而且依赖后端配合。所以现在只在遗留系统里用，新项目一律CORS或代理。还有一个值得提的细节：动态创建script标签如果一直没返回，页面会长时间挂着一个pending的script标签，最好加上超时控制。

iframe配合postMessage是另一个老方案，特别适合跨域嵌入场景，比如A域名页面里用iframe嵌入了B域名的H5页面，两个页面需要通信。父页面可以调用iframe的contentWindow.postMessage发送消息，子页面window.addEventListener('message', ...)接收。反过来子页面也能向父页面postMessage。关键点：接收消息的一方一定要校验event.origin，只处理来自白名单域名的消息，否则任何其他页面都能给这个窗口发消息，又变成注入面了。移动端直播H5页面和宿主App交互时，也经常用类似的跨域通信机制，只是中间往往还会经过JSBridge做一层封装。

3.4 代理方案与Fiddler调试：本地开发怎么绕开跨域

现阶段前端项目本地开发跨域，首选方案其实是代理，而不是让后端到处配CORS。原理也简单：同源策略是浏览器层面的限制，服务端到服务端没有这个限制，那我们就在本地起一个代理服务，让前端请求走代理，由代理转发到目标接口，再把结果返回给本地前端。因为浏览器看到的是和本地同源的地址，根本不会触发跨域检查。

Vite和webpack开发服务器都内置了代理能力。比如在Vite里：

// vite.config.js export default { server: { proxy: { '/api': { target: 'https://api.example.com', changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, ''), }, }, }, };

这样前端代码请求/api/users，Vite开发服务器会把它转发到https://api.example.com/users，浏览器只认识localhost:5173/api/users，一切看起来都是同源的。

但生产环境怎么办？答案是用nginx反向代理，把前端静态资源和后端API放在同一个域名路径下，也不存在跨域。如果后端API必须独立域名，那就要靠网关统一CORS。总之前端开发不要指望“前端能解决生产环境跨域”，跨域问题的最终解释权永远在服务端。

Fiddler在这里扮演的角色是本地调试神器。它作为一个本地HTTP代理，能抓取所有经过它的请求，甚至能修改请求和响应。我知道很多人听到“Fiddler代理配置跨域”一脸懵，其实用法很直接：先用Fiddler抓包，找到那个跨域请求，然后利用Fiddler的AutoResponder或FiddlerScript给响应头注入Access-Control-Allow-Origin，或者干脆把响应延迟、重写、转发到本地mock数据。配置HTTPS请求时，需要先安装Fiddler的根证书，否则只能看到加密后的乱码。

Fiddler还可以用来模拟弱网、延迟、超时，这在排查接口性能问题时也很实用。但必须强调一句：Fiddler改的只是你本地的调试行为，它不影响服务器实际配置，也不代表线上环境已经支持跨域。有人用Fiddler把本地跨域调通了，以为后端不用管了，结果线上照样报错，这个坑一定要避免。

4. Git实战：从安装配置到分支合并的完整闭环

4.1 环境配置：安装、全局身份和SSH认证失败排查

Git是协作开发的基石，第15天我把精力主要放在实战场景上，先从环境配置说起。安装Git没什么难度，windows直接下载安装包，macOS用brew install git都行，装完在终端跑一下git --version确认成功即可。最重要的是全局身份配置，这一步漏了，提交时会报“Please tell me who you are”：

git config --global user.name "你的名字" git config --global user.email "你的邮箱" git config --list # 查看当前生效配置

每次提交记录都会带上这个名字和邮箱，所以最好用真实信息，不要写一些乱七八糟的昵称，后面做代码评审时队友看到“root”这种提交人，心里会犯嘀咕。

接下来是SSH认证。很多新人用HTTPS地址克隆远程仓库，每次push都要输密码，麻烦不说，还会遇到凭据失效问题。更规范的做法是生成SSH密钥对，然后把公钥添加到GitHub、Gitee或公司GitLab后台。

ssh-keygen -t ed25519 -C "[e-mail]" # 一路回车即可，也可以自定义密钥文件路径 cat ~/.ssh/id_ed25519.pub

把输出的公钥内容添加到远程仓库的SSH Keys设置里，然后验证：

ssh -T [e-mail] # 出现 Hi username! You've successfully authenticated 表示成功

如果验证时提示Permission denied (publickey)，常见原因有这么几个：公钥没添加到远程仓库，或者添加的不是当前机器的公钥；本地存在多个密钥文件，SSH默认使用了错误的私钥；Windows环境下密钥权限不对。我处理过最典型的一例：同事电脑里同时有公司GitLab和个人GitHub两套密钥，SSH连接时默认读取的是id_rsa，导致公司仓库一直认证失败。解决办法是在~/.ssh/config里按Host别名指定不同的IdentityFile：

Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github Host gitlab.company.com HostName gitlab.company.com User git IdentityFile ~/.ssh/id_ed25519_company

配合ssh -T [e-mail]逐个验证，双账号问题一次解决。IDE创建新项目拉取Git也类似，本质就是填仓库地址和本机SSH密钥，IDE会调用Git命令完成clone，如果IDE提示认证失败，先回终端跑一遍上面的验证命令，通常问题立刻暴露。

4.2 日常命令体系：提交、查看、回退，一个都不能少

Git命令虽然多，但日常核心高频的其实就十几个。这里整理一张速查表：

场景	命令	说明
查看状态	git status	显示工作区、暂存区变化
查看差异	git diff	看未暂存的具体改动
暂存文件	git add <file>	加入暂存区，可用git add -p交互式部分暂存
提交	git commit -m "message"	提交暂存区内容
查看历史	git log --oneline --graph --all	直观看提交图和分支情况
撤回暂存	git reset HEAD <file>	把文件移出暂存区，保留改动
临时保存	git stash	暂存所有未提交改动，切换分支后git stash pop恢复
回退提交	git reset	见下文三种模式
撤销修改	git checkout -- <file>	丢弃工作区改动，谨慎使用

提交信息规范我建议团队内部统一一下。最基础的要求是：feat:、fix:、docs:、refactor:这类前缀标明类型，后面跟清晰的一句话描述，比如fix: 修复登录页在Safari下按钮错位。不要写“update”“修改bug”这种天书提交信息，封装除了你自己没人看得懂。

git add -p这个命令值得单独推荐。开发时经常一个文件里既有修复又有新功能，直接git add file会把两个逻辑混在一条提交里，评审时非常难读。交互式暂存可以只把某个文件的某几行加入暂存区，让提交粒度保持纯净——一条提交只做一件事。

git reset有三种模式，我经常看到有人在这里翻车。简单记：--soft只挪动HEAD指针，工作区和暂存区都不动，适合想重新提交；--mixed是默认模式，挪动HEAD并清空暂存区，但工作区改动保留，适合把“误加进暂存区”的文件放出来；--hard直接丢弃工作区改动，代码瞬间回到指定版本，危险性最大。我的习惯是：任何--hard之前，先git stash或者主动备份一下，防一手误操作。还有一种回退工具叫git revert，它不会改写历史，而是新生成一条提交来反向改动，适合已经push到远程的分支，因为reset改写了提交历史，再push会被远端拒绝。

4.3 分支与合并：冲突解决才是真正的实战考点

分支是Git的灵魂，通常团队会约定main为主干，功能开发在feature分支上进行，完成后合并回主干。新建并切换分支一行命令搞定：

git checkout -b feature/user-login # 或者新版Git用 git switch -c feature/user-login

开发完成后，需要把feature分支合并到main。常见两种合并方式：merge和rebase。merge会保留两条分支的完整历史，生成一个合并提交，特点是安全、可追溯，但历史图会有分叉；rebase会把当前分支的提交“变基”到目标分支最新提交之后，历史是一条直线，看起来更干净，但会改写提交哈希，所以rebase不该用在已经push出去的公共分支上。

团队协作中真正让人头皮发麻的是合并冲突。冲突的本质是两个人改了同一文件的同一区域，Git不知道谁说了算。解决流程并不复杂：

1. git merge后在冲突提示里查看冲突文件列表；
2. 打开冲突文件，找到类似下面的标记：

<<<<<<< HEAD 这边的代码是你当前分支的内容 ======= 那边的代码是被合并分支的内容 >>>>>>> feature/user-login

3. 手动决定保留哪段、删掉哪段，或者两段都保留一部分，同时把<<<<<<<、=======、>>>>>>>这些标记行全部删掉；
4. git add该文件，然后继续合并流程，直到提交完成。

我之前犯过一个低级错误：解决冲突时只看了自己写的代码，把对方刚加进去的校验逻辑顺手删了，结果上线后线上接口直接报错。所以现在遇到冲突文件，我一定会先git diff看清楚合并前后的差异，再和当事人确认一下，绝不闷头乱删。另一个实用技巧是：每次开发前先git pull --rebase拉取远端最新代码，把冲突提前暴露到自己的分支上，而不是等合并时一次性大爆发。

4.4 完整实战流程：从拉取项目到Push回远程

最后用一条完整流程把这些命令串起来，这也是实际工作的标准路径。假设远程仓库地址是[e-mail]:team/frontend.git：

# 克隆远程仓库到本地 git clone [e-mail]:team/frontend.git # 进入项目目录后建功能分支 cd frontend git checkout -b feature/user-login # 开发完成后查看变更、暂存、提交 git status git diff git add src/pages/Login.vue src/api/user.js git commit -m "feat: 完成用户登录功能" # 拉取远端最新代码并变基，尽量保证本地分支基于最新main git pull --rebase origin main # 推送功能分支到远程 git push -u origin feature/user-login

推送成功后，就可以在GitLab/GitHub上发起Merge Request，等评审通过后合并到main。合并完，远程功能分支就没必要保留了，本地也可以清理掉：

git push origin --delete feature/user-login git branch -d feature/user-login

发布的时候，很多团队会用标签记录版本号。比如发布v1.2.0时：

git tag -a v1.2.0 -m "release: 版本1.2.0" git push origin v1.2.0

标签的好处是，线上出问题时能快速切到对应版本排查代码，而不是靠直觉猜测“当时线上跑的是什么”。这跟前面说的前端强制刷新页面的逻辑是配套的：前端打包资源带内容指纹，发布时Git打对应版本tag，哪次发布出问题，直接查那次tag对应的代码和资源，定位速度会快很多。

遇到push被拒绝，通常是因为本地和远端分支出现了分叉。解决办法是git pull --rebase把远端提交先拉下来，解决冲突后再git push。如果这条分支已经发布了PR，我更倾向于git pull --rebase而不是git pull，因为后者会产生额外合并提交，让PR历史变得混乱。Git的实操没有太多玄学，多踩几次坑、多读几遍错误提示，时间久了自然顺手。

这五天学下来，我最大的体会是：遇到前端问题，先别急着改代码，先问一句“这一步到底是浏览器做的，还是服务器做的，还是Git仓库状态导致的”。HTTP状态码告诉你请求对错，浏览器Network面板告诉你资源加载细节，CORS报错告诉你安全策略拦在哪一层，Git报错告诉你协作历史里发生了什么。把这四块连成一条线后，很多以前看起来无缘无故的报错，其实都能一步步推出来。如果你也在这几个主题上卡过壳，建议不要孤立地背面试题，试着把一次真实的接口联调从头跟到尾，跟着Network里的请求、跨域报错的响应头、Git提交历史走一遍，比看十篇教程都有用。