老广

嗯，很好的建议，尤其是标签那里应该这么做。 总结一下什么场景是比较适合这个的呢， 这种多对多，只是一个容器，或者标签，没有太多别的字段，比如说 **标签** 和 **用户组**，对于 **节点** 来说，多少有点不合适，因为节点有层级关系 对于复杂的多对多，可以提供弹窗式添加，这样会比较友好

> 有时候也没办法，做着做着，就不好使用了

非常开心收到反馈，我们也是基于以上的一些问题，开启了 v3 之旅 1. 抛弃系统用户 Js 刚开始主要考虑的是易用，一个系统用户，自动推送，密码（密钥）是隐藏的，普通用户不会接触。但随着发展，或者等保要求，对账号提出了要求，复杂度、定时改密 等。随着用户越来越多，也收到了他们真实环境的反馈，所以我们在做这方面的调整，放弃系统用户，回归账号本身 2. 账号特权 其实账号特不特权，更多是在维护者的定义，js 中目前也只是个标记，或者筛选的条件，或者用来提权的范围 3. 授权体系 这里你可能没有去做好细化授权规则。JS 是可以指授权某个资产上的某个系统用户的，但是如果你的资产上或者资产所在节点被重复授权了，才会出现多个系统用户 @ttkanni

@shuboGe 这个未来会做

你为什么要在容器里操作 ? rm -rf 怎么避免 ?