调用 Magento 2 REST API 返回 401 Unauthorized，首先区分“没有通过身份认证”和“已经认证但没有资源权限”。401 多数表示 Token 缺失或无效；权限不足也可能因接口配置和认证类型不同返回 401 或 403，因此要保留响应正文与请求路径。

先发送一个最小、可重复的请求

BASE_URL='站点地址'
TOKEN='有效的访问令牌'
curl -i -H \"Authorization: Bearer $TOKEN\" \
  -H 'Content-Type: application/json' \
  \"$BASE_URL/rest/V1/store/storeViews\"

确认 Authorization 中 Bearer 与 Token 之间有空格，Token 没有被引号、换行或日志模板截断。不要把真实 Token 写入代码仓库、工单或公开日志。若同一命令在服务器上成功、通过 CDN 失败，检查代理是否转发 Authorization 请求头。

不同 Token 的权限来源不同

管理员 Token 继承管理员角色权限；客户 Token 只能访问标记为 self 或允许客户的资源；Integration Token 则受该集成选择的 API Resources 控制。接口能用管理员 Token 访问，不代表客户 Token 也应该访问。确认令牌没有因管理员密码修改、集成停用或安全策略而失效。

自定义接口必须在 etc/webapi.xml 声明资源：

<route url=\"/V1/alwayly/items/:id\" method=\"GET\">
    <service class=\"Alwayly\\Api\\Api\\ItemRepositoryInterface\" method=\"getById\"/>
    <resources>
        <resource ref=\"Alwayly_Api::items_read\"/>
    </resources>
</route>

对应 ACL 资源必须在 etc/acl.xml 存在，并分配给调用方角色。使用 anonymous 或 self 应基于真实业务边界，不能为了消除 401 就把管理接口公开。

同时确认路由和商店代码

REST 路径可包含商店代码。错误的 store code 通常返回其他错误，但自定义路由、URL Rewrite 或 WAF 也可能提前拦截。比较 Web 服务器 access log 中的路径、状态和上游响应，确认请求真正到达 Magento。

修复后至少验证四种结果：有效令牌访问允许资源成功；无令牌返回拒绝；权限不足的令牌不能越权；令牌被停用后立即失效。只有成功请求和拒绝请求都符合预期，认证配置才是安全的。