CSS 的 [class$="value"] 属性选择器之所以看起来“失效”，核心原因在于 `class` 属性本身是一个**由空格分隔的类名字符串列表**，而不是单独的后缀字段。实际开发中，目标类名通常并不会刚好位于整个 class 字符串的末尾，例如 `"param x-control-ui"` 中，虽然包含 `x-control-ui`，但并不满足整个属性值以指定字符串结尾的条件，因此 `$=` 无法正确匹配。
CSS 的 `[class$="value"]` 属性选择器不能准确匹配“类名以某字符串结尾”的场景，根本原因是 `class` 属性值本质上是空格分隔的多个类名组合，而不是单个 class 名。很多人误以为它会检查某个类名是否以指定后缀结束，但实际上 `$=` 判断的是**整个 class 属性值**是否以目标字符串收尾，因此在真实项目中经常匹配不到。
放到实际 HTML 中理解会更清楚：class 属性本质上是一个由多个类名组成、以空格分隔的字符串列表，从语义上说，类名的先后顺序并不影响元素效果。也就是说，像 class="param x-control-ui" 和 class="x-control-ui param" 这样的写法，在 HTML 和 CSS 语义上是等价的。但 CSS 属性选择器 [attr$="value"] 的判断方式不同，它要求属性值必须严格以指定字符串结尾。换句话说，它检查的是整个 class 字符串最后是否正好是 -control-ui，而不是判断某一个独立类名是否带有这个后缀。
以你的示例来说：
这里的 class 属性值实际上是 "param x-control-ui"。从表面看它似乎包含了目标后缀，但 CSS 选择器判断的是整个字符串是否以 -control-ui 结尾。由于它最终结尾部分并不符合独立类名匹配的预期，因此：
document.querySelectorAll("[class$='-control-ui']"); // → []即使一开始手动写成 class="x-control-ui"，看起来暂时能够被选中，但在前端开发中，框架、组件库或 JavaScript 脚本往往会动态追加其他类名，例如 hidden、active、is-dirty 等。一旦新增这些类名，class 属性值就会变成 "x-control-ui hidden"，此时 [class$="..."] 同样会立即失效。这也是为什么这种写法在实际页面中非常脆弱、可维护性差且不稳定。
✅ 正确做法：不要依赖 class 字符串的位置关系，而应采用更语义化、更稳定的 class 命名和选择方式：
分离关注点：为通用控制逻辑定义基础类（如
control-ui），再用修饰类描述具体类型：x-control:
y-control:
对应选择器：
document.querySelectorAll(".control-ui");// 所有控件 document.querySelectorAll(".control-ui--x"); // 仅 x 类型*使用 `data-` 属性增强语义（尤其推荐用于 JS 交互和 DOM 查询）**：
document.querySelectorAll("[data-control-type]"); document.querySelectorAll("[data-control-type='x']");如果确实需要通过属性选择器匹配
class，相对安全一些的宽松方案是[class*="-control-ui"]，不过它也会带来误匹配风险，例如zoo-control-ui-extra这类 class 同样会被选中。因此更稳妥的方式，是配合.classList.contains()在 JavaScript 中做精确判断：Array.from(document.querySelectorAll("[class]")) .filter(el => el.classList.contains("x-control-ui"));
⚠️ 总结：[class$="..."] 并不适合用来判断某个 class 名是否带有指定后缀，因为它匹配的是整个 class 属性字符串，而不是类名列表中的单个项。在真实项目、组件化开发和动态 class 场景下，这种写法几乎都会出现失效或不稳定的问题。更推荐使用明确的类名设计、data-* 属性、classList API，以及清晰可预测的 CSS 选择策略，才能让代码更健壮、更易维护，也更符合现代前端开发最佳实践。
