每天进步一点点（前端）

nodejs 如何充分利用多核 CPU?

总所周知， NodeJS 是单线程执行任务， 不同于 浏览器还可以使用 web worker 等手段多线程执行任务。那么 NodeJS 中， 是如何充分利用物理机的多核 CPU 呢？
有三种方式
        1.在 Node.js 中，JS 也是单线程的，只有一个主线程用于执行任务。但是，在 Node.js 中可以使用多进程来利用多核机器，以充分利用系统资源。

        2.Node.js 提供了 cluster 模块，可以轻松创建子进程来处理任务。通过将任务分配给不同的子进程，每个子进程可以在自己的线程上执行任务，从而实现多核机器的利用。
        3.Node.js 也提供了 worker_threads 模块，可以创建真正的多线程应用程序。这个模块允许开发者创建和管理多个工作线程，每个线程都可以独立地执行任务。
        利用的是 Node.js 的事件循环机制和异步非阻塞的 I/O 操作。Node.js 使用事件驱动的模型来处理请求，当有请求到达时，Node.js 将其放入事件队列中，然后通过事件循环来处理这些请求。在等待 I/O 操作的过程中，Node.js 不会阻塞其他请求的处理，而是继续处理其他请求。这样，即使 JavaScript 是单线程的，但在实际运行中，多个请求可以同时处理，充分利用了多核系统的能力。

cookie 可以实现不同域共享吗?

默认情况下，Cookie 不能在不同的顶级域名之间共享数据。
但是，如果两个域名属于同一主域名下的子域名，并且您设置了正确的 Domain 属性，那么在这些子域名之间是可以共享 Cookie 的。
例如，对于 sub1.example.com 和 sub2.example.com 这样的子域名，如果设置 Cookie 的 Domain 属性为 .example.com ，那么在这两个子域名之间，这个 Cookie 是可以共享和访问的。
然而，如果是完全不同的顶级域名，如 example.com 和 anotherdomain.com 之间，Cookie 是不能直接共享的。
此外，还需要注意 Cookie 的 Path 属性、安全属性（Secure）、HttpOnly 属性等，这些属性也会影响 Cookie 的使用范围和方式。 

hooks 调用是可以写在 if 语句里面吗?

hooks 写在 if 语句里面， 也是可以执行的， 但是会带来很多不可预期的异常
在 React 中，Hooks 的调用不应该直接写在 if 语句里面。
Hooks 必须在函数组件的顶层（不在循环、条件判断或嵌套函数中）按顺序调用。这是因为 React 需要在每次渲染时以相同的顺序调用 Hooks，以正确管理组件的状态和副作用。
如果在 if 语句中调用 Hooks，可能会导致以下错误：
状态不一致：由于渲染顺序的不确定性，可能会导致状态的更新和获取出现不一致的情况。
难以预测的行为：React 依赖于 Hooks 的调用顺序来正确管理组件的内部逻辑，如果在条件语句中调用，可能会导致难以理解和调试的问题。
例如，下面的代码是错误的：
function MyComponent() {
  if (someCondition) {
    const [count, setCount] = useState(0); // 错误：不允许在条件语句中调用 useState
  }

  // 后续代码
}
为了遵循规则，应该将 Hooks 的调用始终保持在函数组件的最顶层。

 

浏览器有同源策略， 但是为何 cdn 请求资源的时候不会有跨域限制?

同源策略是啥?
浏览器的同源策略（Same-origin policy）是一种重要的安全机制，用于限制不同源的文档或脚本之间的交互操作。
“源”（origin）由三部分组成：协议（protocol）、域名（domain）和端口（port）。如果两个 URL 的协议、域名和端口都完全相同，那么它们就是同源的；否则，就是不同源的。
同源策略的主要作用和规则如下：
1、阻止文档或脚本读取来自不同源的文档内容
    比如，在 https://example.com/page1.html 页面中的 JavaScript 脚本，不能读取 https://anotherdomain.com/page2.html 的文档内容。
2、限制不同源的脚本之间的交互
    不同源的脚本不能相互调用方法、访问对象属性或修改对方的 DOM（文档对象模型）。
3、限制跨源的网络请求
    例如，使用 XMLHttpRequest 或 Fetch API 发起的网络请求，如果目标地址与当前页面的源不同，会受到同源策略的限制。不过，一些跨源请求可以通过 CORS（跨源资源共享，Cross-Origin Resource Sharing）机制来实现合法的跨源访问。

同源策略的目的是防止恶意网站窃取用户在其他网站上的敏感信息或进行未经授权的操作，保护用户数据的安全性和隐私性。
举个例子，如果没有同源策略，恶意网站 malicious-site.com 可能会在其页面中嵌入脚本，尝试读取用户正在访问的银行网站 bank-site.com 的页面内容，获取用户的账户信息、交易记录等敏感数据，这将给用户带来极大的安全风险。
浏览器有同源策略， 但是为何 cdn 请求资源的时候不跨域
一些 CDN 资源不受同源策略限制，是因为同源策略主要是浏览器的一种安全机制，用于限制不同源的文档或脚本之间的交互操作，但对于某些特定类型的资源访问，浏览器会有一些例外情况。
在 HTML 中，<script>、<img>、<iframe>、<link>等标签的 src 属性所指向的资源（如 JavaScript 文件、图片、CSS 文件等）通常是可以跨域访问的。
例如，可以在自己的网站中通过<script src="https://cdn.example.com/vue.min.js"></script>加载来自 CDN 的 Vue.js 库。
这样做的主要原因是为了保证 Web 的开放性和可扩展性。如果这些资源也严格受到同源策略的限制，那么将所有相关资源都部署在同一个服务器下会违背 Web 开放的初衷，并且不利于资源的分发和缓存。
然而，虽然浏览器允许这些资源的跨域加载，但在加载 JavaScript 时，会限制对返回内容的读写权限，以防止恶意脚本获取或修改其他域的信息。
另外，CDN 服务提供商通常也会采取一些措施来确保资源的安全性和合法性。他们会对资源进行管理和配置，只允许合法的请求访问资源，并防止恶意使用或滥用 CDN 资源。
需要注意的是，同源策略仍然是非常重要的安全机制，它能有效防止恶意网站窃取用户在其他网站上的敏感信息或进行未经授权的操作。在涉及到敏感数据的交互或需要更严格安全控制的情况下，仍然需要遵循同源策略或采用适当的跨域解决方案，如 CORS（跨域资源共享）等。CORS 通过在服务器端设置响应头，明确允许哪些源可以访问资源，从而在保证安全的前提下实现跨域数据交互。
img src 指向的任何资源都是可以跨域访问吗
一般情况下，<img> 元素的 src 属性指向的资源是可以进行跨域访问的。
当您在网页中使用 <img> 标签加载图片资源时，浏览器会向指定的 URL 发送请求获取图片数据，并将其显示在页面上，即使该资源的源与当前页面的源不同。
然而，也存在一些特殊情况和限制：
1、如果图片资源所在的服务器设置了严格的访问控制策略（例如通过服务器端的配置限制某些来源的访问），那么可能会导致您的请求被拒绝。
2、对于一些受版权保护或有特殊访问权限要求的图片资源，如果您没有相应的授权或访问权限，即使浏览器本身允许跨域访问，您也无法获取和显示这些图片。
总的来说，在大多数常规情况下，<img> 元素的 src 属性指向的图片资源能够实现跨域访问，但需要考虑服务器端的配置和资源本身的权限要求等因素。