HTTP认证头的基本作用
在日常上网过程中，我们经常需要登录账号才能访问某些内容，比如查看邮箱、管理个人订单。这些操作背后，很多都依赖HTTP认证头来确认身份。它就像一张电子通行证，告诉服务器‘我是谁’，从而决定能不能进入。
HTTP认证头最常见的形式是Authorization头，它附在请求中发送给服务器。服务器收到后会验证信息，通过了就返回数据，不通过就拒绝访问。
基本使用方式：Base64编码的用户名密码
最简单的用法是HTTP Basic认证。假设你登录某个管理后台，账号是admin，密码是123456，浏览器会把它们拼成字符串“admin:123456”，然后用Base64编码。
编码后的结果是YWRtaW46MTIzNDU2，接着请求头就会变成这样：
Authorization: Basic YWRtaW46MTIzNDU2注意这里的“Basic”是认证类型，不能省略。虽然看起来像加密，但Base64只是编码，并不安全。所以这种认证方式必须配合HTTPS使用，否则密码容易被截获。
实际场景：调用API接口
现在很多手机App或网页前端需要从服务器获取数据，比如查天气、同步笔记。开发者在调试接口时，常会遇到需要添加认证头的情况。
例如，调用一个天气API，服务商要求提供API Key。这时候可能这样设置头信息：
Authorization: Bearer eyJhbGciOiJIUzI1NiIs
eyJzdWIiOiIxMjM0NTY3ODkwIiw
kFtZSI6IkpvaG4gRG9lIn0
.x_qYQ这种叫Bearer Token，常见于OAuth或JWT认证。Token一般由登录接口返回，后续请求都要带上。一旦过期，就得重新登录获取。
浏览器里的小细节
有时候访问一个网站，弹出一个小窗口让你输用户名密码，那就是服务器返回了401状态码，触发了浏览器默认的认证流程。输入后，浏览器会自动把凭证放进Authorization头再发一次请求。
但现代网页更多是用JavaScript在后台处理认证，避免弹窗影响体验。比如登录页面提交表单后，拿到Token存在本地，之后每次请求手动加到头里。
安全提醒：别把认证信息写死在代码里
有人为了方便，把带Authorization的请求直接写在前端代码里，比如做个网页工具查快递。一旦发布，别人就能从源码里扒出你的密钥。
正确的做法是：敏感信息放在服务端，前端只负责传用户自己的Token。哪怕泄露，也只影响单个账户，不会让整个系统崩掉。
生活中类似的情况就像门禁卡。你不会把家门钥匙贴在门上，同样也不该把“电子钥匙”明文暴露在代码或日志里。