网页token获取这事，网页说穿了就三种途径：看浏览器开发者工具、网页查服务器日志、网页翻前端代码。网页大多数时候你只需要第一种。网页

打开Chrome，网页按F12，网页切到Network标签页。网页刷新页面，网页随便点一个请求，网页在Headers里找Authorization字段。网页token通常长这样：`Bearer eyJhbGciOi...`，网页一长串乱码似的网页字符。如果你找的网页是登录后的token，那就在登录接口的网页响应里翻——点开那个叫login或auth的请求，看Response或者Preview，里面会有`access_token`、`token`之类的键名。

有个坑得提醒你。有些网站把token放在Cookie里，而不是Authorization头。这时候你得去Application标签页，左侧找Cookies，点开当前域名，里面那个叫`sessionid`或`token`的玩意儿就是。但Cookie里的token往往被HttpOnly标记保护着，你虽然能看到它存在，却没法用JavaScript读取——这是安全设计，别想着绕过。

再一种情况，token藏在URL参数里。比如你访问某个页面，地址栏后面跟着`?token=xxx`或`?access_token=xxx`。这种情况多见于第三方登录回调，比如你用微信扫码登录某个网站，跳转回来的URL里就带着临时token。抓这种token最简单，直接看地址栏就行。

如果以上都找不到，那就得翻前端代码了。在Sources标签页里搜索`token`这个关键词，Ctrl+Shift+F全局搜。看它是在localStorage里读写，还是在内存变量里传递。有次我帮朋友调试一个老系统，token居然被存在了window对象的全局变量里，刷新页面就丢，每次都要重新登录——这种设计糟透了，但确实存在。

说个真实案例。之前调试某个管理后台，怎么都找不到token在哪。翻遍了Network和Application都不见踪影。后来发现他们用了WebSocket通信，token是在建立连接时通过子协议传过去的，根本不走普通HTTP请求。你在Network里看不到，得切到WS标签页，看连接初始化的帧数据。这种冷门情况不多，但遇到了会卡很久。

还有一种更隐蔽的——token放在响应头里。有些后端会把新token放在每个响应的`X-Auth-Token`或`Set-Cookie`里做自动续期。你光看请求头没用，得看响应头。在Network里点开任意一个请求，看Response Headers区域，找那些以`X-`开头的自定义字段。

最后说个野路子。如果页面能正常登录且保持会话，但你死活找不到token——直接看浏览器存储。Application标签页里Local Storage和Session Storage都翻一遍，很多单页应用（SPA）喜欢把token存在localStorage里，键名可能是`user_info`、`auth_data`这种看着不像token的名字，点开看值，里面嵌套着token字段。

实在找不到，那就用笨办法：清空所有存储和Cookie，重新登录，在登录瞬间立刻停住Network面板的录制，看第一个发出的POST请求。那个请求的载荷里通常带着用户名密码，响应里必然带着token。这一步抓不到，说明后端做了加密传输，那你就得考虑用抓包工具（比如Fiddler或Charles）做HTTPS解密了——但那是另一个话题了。