计算属性不构建sku矩阵，而是响应式查询已静态构建的邻接矩阵；矩阵在数据就绪后一次性生成，用于o(1)判断规格共存性，计算属性仅封装canselect和availablevalues等查询逻辑。

计算属性名本身不能“动态构建”矩阵，它只是响应式地推导状态。真正动态构建SKU矩阵的是初始化逻辑和数据结构设计，计算属性负责高效消费这个矩阵并驱动UI反馈。

先建好矩阵，再用计算属性读它

邻接矩阵不是运行时靠计算属性生成的，而是在组件加载或SKU数据就绪后，一次性构建完成的静态二维结构。它的作用是把“哪些规格值能共存”这个关系，从遍历判断变成O(1)查表。

• 顶点列表（vertexList）按规格组顺序排列：比如先放所有颜色值，再放所有尺码值，最后放所有版本值
• 矩阵（matrix）初始全为0，遍历每个SKU，对其中每对规格值（如"红色"和"XL"）在顶点列表中定位索引，将对应 matrix[i][j] 和 matrix[j][i] 置为1
• 这个过程只做一次，后续所有交互都复用该矩阵，不重复构建

用计算属性封装“可选性”判断逻辑

用户点击某个规格项时，是否禁用其他选项，由计算属性实时决定。它不操作矩阵，只查询矩阵：

• canSelect(attr)：检查当前已选的所有规格值，是否都与该 attr.value 在矩阵中连通。只要有一个断开，就返回 false
• availableValues(specName)：比如 specName 是 "尺码"，就遍历所有尺码值，对每个值调用 canSelect，返回全部 true 的集合
• 这些计算属性依赖 selectedSpecs 和 matrix，任一变化都会自动重算，无需手动触发

异步场景下确保矩阵就绪再启用交互

SKU数据通常来自接口，必须等 skus 数组和规格元数据（如 skuAttrSortedList）都加载完成，才能构建矩阵。建议：

• 用 v-if="matrixReady" 控制规格面板渲染，避免空矩阵导致误判
• 在 watch 或 async setup 中，当 skus 和 attrs 都非空时，调用 buildMatrix() 方法生成 vertexList 和 matrix
• 把 matrixReady 设为 computed，依赖 skus.length 和 attrs.length，保证条件明确

大型系统需注意矩阵规模与内存平衡

当规格值总数超过200（例如服装类含颜色×尺码×图案×袖长），邻接矩阵会占用约40KB内存（200×200×1字节）。这时可改用稀疏表示：

• 用 Map> 替代二维数组，key 是顶点名，value 是它能连接的所有顶点名集合
• 计算属性中改用 has() 查询替代 matrix[i][j] === 1，时间复杂度仍为 O(1) 平均情况
• 对超多规格商品（如定制家具），可结合服务端预计算“可选图谱”，前端只加载子图