第一种它取的是admin-cluster 对应上了路径的那个/v1/admin-cluster，这种是对的？
这个权限code是swagger扫描文件然后拼接而成的。具体生成规则是：
- 请求某一个服务的
/v2/choerodon/api-docs接口获取swagger json - code的规则是 服务名 +
.+ controller +.+ method - 解析json，可以拿到服务名，然后去拿所有以
Controller或Endpoint为后缀的类，截取后缀之前的字符串作为controller name，然后遍历controller里的方法，只拿加了@Permission()注解的方法作为method - 生成code后，会到permission表里根据服务名和code两列查询，如果存在记录则更新，如果不存在的话就插入
因为是如上生成规则，所以一个controller类里面不允许有重复的方法名，如果有重复的方法名，会导致其他的重名方法无法插入到permission表中，可能会造成403的问题
你的code里面有个null，排查一下/v1/cluster/open/{organization_id}这个controller类名叫什么，是不是叫NullController。
类名不是null，如果是截图Controller前缀的话，那成功的那列应该是AdminCluster而不是admin-cluster吧
我这边是服务名和方法名是对的 就是中间那个，有的和controller前缀不符合，有的是null
对，正常情况下应该是cluster-vo的，能不能看下ClusterVoController上面加了哪些注解
我按你的代码写了个controller，然后在本地测试，是正常的
你那边能不能在本地测试下，启动java版的注册中心，然后启用iam服务，然后在启动x-devops-service，看看插入到permission表里是什么数据
或者你把null那条数据删掉，然后重启下服务，看看新插进去的记录是什么
我数据库找不到那条语句
对应的code并不是这个
就是把那个xxx.null.add那条记录删掉就行了，然后把对应的服务重启一下
那条数据本身是我手动加的，因为程序启动后并没有对应的信息添加到表中，现在删掉重启也没有自动加入
行吧，那应该不是刷入permission的bug了
我有个疑问，是不是那个controller必须在api->controller包下面才会自动生成，我后面没成功生成的那几个带有null的controller在自定义的web包下，但是为什么方法名是对的呢，就中间的controller前缀是null
默认是applicatoin所在的目录，就是sping boot扫描的目录
上面那个可正常生成 下面那个就有问题，除了这些还有其他需要注意的吗
clusterservice里面的会生成null?看下controller怎么写的
你把这几个null的permissoin删掉，然后重新初始化，还会生成null?
数据库中不会重新生成，但是api测试中可以查到，就算删掉也能查到，而且是null
哦，明白了，那是刷权限没问题，可能是api测试拼接code的时候有问题，我一会看下