根本原因是Postman与浏览器会话隔离，登录态不共享；需手动提取登录接口返回的token（如金蝶云星空的result字段），并注入后续请求Authorization头或指定Header，同时严格校验URL、lcid、Content-Type等参数。
Postman里401但浏览器能正常访问，根本原因是上下文隔离
Postman和浏览器是两个完全独立的会话环境，浏览器登录产生的 Cookie、Session、Token 不会自动同步到 Postman。哪怕你在 Chrome 里刚点完“登录成功”，Postman 发出的请求依然会被判定为未认证——它压根没拿到任何凭证。这不是配置错，而是机制差异导致的必然结果。
常见错误现象包括：401 Unauthorized、"msg": "认证失败,无法访问系统资源"、返回 loginResultType 为 0 或空响应。这类问题 90% 都卡在“以为登录过就万事大吉”这一步。
- 浏览器走的是表单提交 + Cookie 自动携带 + 同源策略下的 Session 共享
- Postman 默认不带任何 Cookie，也不继承浏览器的登录态
- 金蝶云星空等系统要求每次业务请求都显式携带
Authorization头或token参数，否则直接拒收
登录接口返回 token 后，必须手动提取并注入后续请求
金蝶云星空的 /Kingdee.bos.webapi.ServicesStub.authservice.validateuser.common.kdsvc 登录成功后，响应体里会包含一个长字符串字段（通常是 result 或 token），不是放在 Set-Cookie 头里，也不靠 Cookie 维持会话。
你不能只看响应体里有 "loginResultType": 1 就算完事，必须把 token 提取出来，并在后续所有请求中主动带上。否则每个请求都是“裸奔”状态。
- 在登录请求的 Tests 标签页里写脚本提取：
pm.environment.set("access_token", pm.response.json().result); - 确认 token 字段名：金蝶常用字段是
result，不是token或data.token，别凭经验瞎猜 - 在后续请求的 Authorization 标签下选
Bearer Token，值填{{access_token}} - 如果接口文档明确要求放
headers的其他字段（如X-Auth-Token），就得在 Headers 里手动加，不能只依赖 Authorization 标签
端口、路径、lcid 三个参数错一个，登录就静默失败
金蝶云星空对登录请求的校验非常严格，acctid、userName、password 都对，但只要 lcid 或端口不对，返回的仍是 loginResultType: 0 或空响应，不会提示具体原因。
典型陷阱：
-
acctid必须全小写且无空格，写成AcctID或acctId直接失败 - 本地调试时 URL 必须是
http://localhost:1200/k3cloud/...这类映射地址，不能用云服务器真实域名或 IP -
lcid值必须匹配账套语言：简体中文是2052，繁体是1028，写成"2052"（字符串）也会失败，必须是数字类型 - 请求头
Content-Type必须是application/json，漏掉或写成text/plain会导致解析失败，返回 400 或静默 401
Token 过期或被服务端主动失效，Postman 不会提醒你
金蝶的 token 通常有 30 分钟有效期，且同一账号重复登录会令旧 token 失效。Postman 不会像浏览器那样自动跳转登录页，它只会一直发过期 token，直到你手动刷新。
最容易被忽略的点：你以为 token 没变，其实服务端已经把它作废了。这时候再怎么检查 Authorization 设置都没用。
- 打开 Postman Console（View → Show Postman Console），看实际发出的请求头里
Authorization值是否为空或明显异常 - 把
{{access_token}}值复制到 jwt.io 解码，检查exp字段是否已过期 - 在登录请求 Tests 里加一行日志：
console.log("New token saved:", pm.environment.get("access_token").substring(0,20) + "...");，确认每次登录是否真生成了新 token - 不要复用别人给的 token 字符串——金蝶 token 绑定客户端 IP 和设备指纹，跨机器使用大概率失败
真正麻烦的从来不是“怎么配”，而是“配完以为对了，其实某个小写字段或端口映射早就在后台悄悄否决了整个流程”。每次 401，先砍掉上下文幻觉，从登录请求的原始响应开始逐字比对字段名、类型、URL、头信息，比重装插件有用得多。
