scoped原理、穿透原理、哈希计算

什么是socped

当一个style标签拥有scoped属性时，它的CSS样式就只能作用于当前组件，通过该属性，可以使组件之间的样式不相互污染。也就是实现组件私有化，起到样式隔离的作用

原理

1. 为组件实例生成一个唯一的标识，给组件中的每个标签对应的dom元素添加一个标签属性，data-v-xxxx,也叫做组件ID
2. 给 < style scoped>中的每个选择器的最后一个选择器添加一个属性选择器，原选择器[data-v-xxxx],如：原选择器为.container #id div，则更改后的选择器为.container #id div[data-v-xxxx]

引出另外一个问题：
如果使用第三方组件，加了scoped之后就可能控制不到第三方组件中的样式了。（例如element-ui）

所以这时候需要样式穿透
样式穿透的写法有两种：/deep/、::v-deep、>>>(这种写法比较老)

样式穿透原理：
scoped后选择器最后默认会加上当前组件的一个标识，比如[data-v-xxxx]用了样式穿透后，同样可以通过这个标签属性来对其进行样式权重的控制。不会在选择器后面追加[data-v-xxxx]

样式穿透原理指的是当元素存在嵌套时,某个元素可以直接使用父元素的样式,也就是说当我们给父元素定义一个样式时,子元素可以直接使用,不需要重新定义。这种机制叫做样式穿透原理。 原理解释:样式穿透原理是计算机中选择器的优先级选择原理,即当选择器存在嵌套时,父元素中定义的样式可以被子元素继承,同时子元素也可以重新定义样式,且优先级将高于父元素的样式

data-v-xxxx

xxxx值是怎么得到的？
webpack+vue-loader对vue2的处理

// vue-loader/src/index.ts
  
  const shortFilePath = path
    .relative(rootContext || process.cwd(), filename)
    .replace(/^(..[/\])+/, '').replace(/\/g, '/')
  
  const id = hash(
    isProduction
      ? shortFilePath + '\n' + source.replace(/\r\n/g, '\n')
      : shortFilePath
  )

vite+@vitejs/plugin-vue对vue3的处理

// vite-plugin-vue/src/util/descriptorCache.ts
  
import path from "node:path";
import { createHash } from "node:crypto";
import slash from "slash";

function getHash(text) {
  return createHash("sha256").update(text).digest("hex").substring(0, 8);
}

// 获取文件相对路径
const normalizedPath = slash(path.normalize(path.relative(root, filename)));
// 计算 ID
descriptor.id = getHash(normalizedPath + (isProduction ? source : ""));

可以发现，不管是 vue-loader 还是 @vitejs/plugin-vue ，data 属性 ID 的生成机制都是一样的，即：

• 开发环境下会根据文件相对路径生成唯一 ID，比如 vite 中 src/App.vue 固定生成 7a7a37b1
• 生产环境下会根据文件相对路径+文件内容共同生成唯一 ID
  注意：相同路径结构的 Vue 子应用的组件，在开发环境下会产生样式冲突，但在生产环境下大概率不会，除非文件内容完全一样。
  那如果遇到了冲突问题，除了手动修改文件路径或文件名，还有什么办法可以完全避免？

给 Vue 提 PR ！ 一个更好的 ID 计算方式是加上项目名(或者 package.json 的 name)，并支持手动指定，这样就可以彻底避免冲突问题了。

import path from "node:path";
import { createHash } from "node:crypto";
import slash from "slash";

function getHash(text) {
  return createHash("sha256").update(text).digest("hex").substring(0, 8);
}

// 获取项目名
const projectName = config.projectName || path.basename(root)
// 获取文件相对路径（含项目名）
const normalizedPath = slash(path.normalize(path.join(projectName, path.relative(root, filename))));
// 计算 ID
descriptor.id = getHash(normalizedPath + (isProduction ? source : ""));

为什么开发环境和生产环境的 ID 计算方式不一样？

首先，开发环境下最好不要加入文件内容进行 hash 计算。
这很好理解：

一来 hash 计算是耗时的，内容越多耗时越长；
二来还会频繁变动节点样式，徒增成本。

那生产环境为什么还要加入文件内容计算 hash ？
如果 ID 与文件内容无关，就可以实现稳定的 data 属性。对于 E2E （端对端）测试用例，就可以直接使用 data 属性进行元素寻址。

为什么在生产环境中要将文件内容纳入哈希计算？

在生产环境中，将文件内容纳入哈希计算主要是为了解决缓存问题和版本控制。
在Web开发中，为了提高网站的加载速度和性能，通常会将静态资源（如CSS、JavaScript文件）进行缓存。当浏览器首次加载网页时，会将这些资源下载到本地，并根据资源的URL进行缓存。当用户再次访问同一网页时，浏览器会先检查缓存，如果资源没有发生变化，则直接使用缓存的资源，从而提高加载速度。

然而，如果在生产环境中对静态资源进行修改，而URL没有发生变化，浏览器可能仍然使用缓存的旧资源，导致网页显示不正确或出现错误。为了解决这个问题，可以使用哈希计算。

哈希计算会将文件的内容计算出唯一的哈希值，并将其添加到文件名或URL中。当文件内容发生变化时，哈希值也会随之改变。这样，浏览器在加载网页时就会发现URL发生了变化，从而强制重新下载最新的静态资源。这保证了用户总是能够看到最新的文件版本，同时也解决了缓存问题。