配置CONSUL_HTTP_TOKEN后npm consul客户端创建ACL仍报Permission denied

结合日志和配置内容，能直接定位两个核心触发因素，导致持续返回权限拒绝：

1. 环境变量赋值不符合规范 #

当前设置的CONSUL_HTTP_TOKEN环境变量，值是consul acl bootstrap命令输出的整段多行全量文本，并非单独提取的合法令牌值。

日志中打印的变量内容完全匹配这个特征：

Bootstrap token is  AccessorID:       9d0d8271-b8aa-6b03-c4f5-dce653853653
consul_1  | SecretID:         f4a6ffc0-2a16-517e-d1c5-645eaaeb5f7a
...
（后续跟着令牌描述、关联策略列表等多行内容）

合法的全局管理令牌，应该是纯UUID格式的SecretID值，也就是f4a6ffc0-2a16-517e-d1c5-645eaaeb5f7a这串内容。现在客户端带着整段带换行、带说明文字的非法值发起请求，Consul服务端根本无法匹配到对应带global-management权限的身份，直接命中默认的deny策略，返回403。

2. 调用的接口版本不兼容 #

代码中使用的consul.acl.create方法，对应Consul早期ACL v1版本的遗留创建接口，请求路径为/v1/acl/create，和日志里记录的请求地址完全一致。当前Consul 1.4之后的版本已经全面切换到ACL v2体系，默认不开启旧接口的兼容逻辑。

注意：因为当前配置的default_policy是deny，Consul对未授权的请求不会返回明确的“接口不存在”提示，而是统一返回Permission denied的403错误，很容易和令牌错误的问题混淆。

• 重新正确设置环境变量：不要把bootstrap命令的全量输出作为环境变量值，需要单独提取SecretID字段对应的纯UUID值。Linux环境下可以用命令快速提取赋值：

  export CONSUL_HTTP_TOKEN=$(consul acl bootstrap | grep 'SecretID:' | awk '{print $2}')
  

• 替换代码中的创建方法：将旧的consul.acl.create调用，替换为适配ACL v2的consul.acl.token.create，对应新版的接口路径，和当前Consul版本的接口逻辑匹配。
• 客户端初始化校验：无参初始化consul客户端时，确认没有手动传入覆盖性的token配置，保证客户端从环境变量读取的是正确的纯UUID格式令牌。

内容的提问来源于stack exchange，提问作者Ajay Sabarish