javaScript 中一起走过的那些场景

文章目录

• • js 立即执行函数能否访问到全局变量
  • 不同网站之间的存储可以互读嘛
  • 什么是CDN
  • 深浅克隆以及特殊应用
  • • 函数克隆实例
  • JWT 鉴权
  • • token 放在url中行否

js 立即执行函数能否访问到全局变量

JavaScript中的立即执行函数可以访问到全局变量。

1. 原理

   • 在JavaScript中，全局变量是在全局作用域中定义的变量。立即执行函数虽然有自己的函数作用域，但它可以访问到其外层作用域（包括全局作用域）中的变量。这是因为JavaScript的作用域链的特性，当在一个函数内部访问一个变量时，它会先在自己的作用域中查找，如果找不到，就会沿着作用域链向外层作用域查找，直到找到该变量或者到达全局作用域。

2. 示例代码

   • 以下是一个简单的示例，展示立即执行函数访问全局变量的情况：

   var globalVariable = "I am a global variable";
   (function () {
       console.log(globalVariable); 
   })();
   

   • 在这个例子中，定义了一个全局变量globalVariable，然后在立即执行函数内部通过console.log输出这个变量。由于立即执行函数可以访问到全局作用域中的变量，所以可以成功地打印出globalVariable的值。

3. 闭包与全局变量访问

   • 立即执行函数也可以通过闭包的形式来访问和操作全局变量。例如：

   var globalVariable = 10;
   (function () {
       var localVariable = 5;
       function add() {
           return globalVariable + localVariable;
       }
       console.log(add());
   })();
   

   • 在这里，立即执行函数内部定义了一个局部变量localVariable和一个函数add。add函数通过闭包的方式访问了外部的全局变量globalVariable和局部变量localVariable，并返回它们的和。这种方式展示了立即执行函数内部可以灵活地结合全局变量和自身的局部变量来实现复杂的逻辑。

4. 注意事项

   • 虽然立即执行函数可以访问全局变量，但是过多地依赖全局变量可能会导致代码的可维护性和可读性变差。因为全局变量可以在代码的任何地方被修改，这可能会引入一些难以调试的错误。所以在实际开发中，应该谨慎使用全局变量，尽量将变量的作用域限制在需要的范围内。

不同网站之间的存储可以互读嘛

1. 同源策略限制
   • 通常情况下，由于浏览器的同源策略，不同网站之间的存储不能直接互读。同源策略是一种安全机制，它规定只有协议、域名和端口完全相同的网页才能相互访问彼此的数据。例如，http://example1.com和http://example2.com是不同源的，它们的本地存储（如localStorage）和会话存储（如sessionStorage）默认是不能互相读取的。
   • 以localStorage为例，它是基于域名进行隔离存储的。如果一个网页试图读取另一个不同源网站的localStorage内容，浏览器会阻止这种行为，这是为了防止恶意网站窃取用户在其他网站上存储的数据，保护用户隐私和数据安全。
2. 跨域存储访问的例外情况
   • 通过跨域资源共享（CORS）
     • 当服务器端配置了适当的CORS策略时，在一定条件下可以实现跨域数据访问。例如，服务器允许某个特定的外部域名进行跨域请求，并且在响应头中设置了允许访问的存储相关信息。但是这种方式主要是针对网络请求（如Ajax请求获取数据），对于像localStorage这种本地存储的跨域读取通常不会直接因为CORS而允许。
   • 使用第三方库或框架的特殊机制
     • 有些第三方库可能会提供一些跨域存储访问的机制，但这往往也需要服务器端的配合。例如，一些用于单点登录（SSO）的库，它们可能会通过在不同域名之间传递加密的令牌来共享用户的认证状态，在一定程度上实现跨域存储相关信息的交互，但这并不是直接的存储互读。
   • 通过浏览器扩展
     • 浏览器扩展可以在一定程度上绕过同源策略进行存储访问。不过，这种方式需要用户安装特定的扩展，并且扩展本身也需要遵循一定的安全规则和权限设置。而且，恶意的浏览器扩展可能会滥用这种权限，导致用户数据泄露，所以浏览器对于扩展的审核和管理也比较严格。
3. 跨域存储解决方案
   • 服务器代理
     • 可以在同源的服务器上设置代理服务器。例如，网站A想要获取网站B的数据，它可以向自己的服务器发送请求，然后服务器通过合法的跨域请求（如配置了CORS的Ajax请求）从网站B获取数据，再将数据返回给网站A。这样就间接实现了跨域数据访问，而不会违反同源策略对存储互读的限制。
     • 不过这种方法增加了服务器的负担，并且需要对服务器进行适当的配置和维护。
   • HTML5的跨文档消息传递（postMessage）
     • 这种方法允许不同源的文档之间进行消息传递。虽然它不是直接的存储互读，但可以用于在不同源的网页之间传递数据相关的指令或信息。例如，网站A可以通过postMessage向网站B发送一个请求消息，网站B收到消息后可以根据请求进行相应的操作，如从自己的存储中获取数据并通过postMessage返回给网站A。

什么是CDN

1. CDN的定义
   • CDN即内容分发网络（Content Delivery Network），是一种通过在网络各处放置节点服务器来构成的在现有的互联网基础之上的一层智能虚拟网络。这些节点服务器能够按照一定的规则缓存需要频繁访问的静态内容，如图片、样式表、脚本文件、视频等。
2. CDN的工作原理
   • 用户请求阶段
     • 当用户在浏览器中请求访问一个网页或其他资源时，请求首先会到达离用户地理位置最近的CDN节点（也称为边缘服务器）。这是通过DNS（域名系统）解析来实现的。例如，当用户在浏览器中输入一个网站的域名时，DNS服务器会根据用户的地理位置和CDN服务商的配置，将域名解析到距离用户最近的CDN节点的IP地址。
   • CDN节点处理阶段
     • 边缘服务器会检查自己的缓存中是否已经存储了用户所请求的内容。如果缓存中有该内容，就直接将其返回给用户。这大大缩短了数据传输的距离和时间，因为数据是从离用户较近的服务器发送的，而不是从源服务器（可能位于较远的地理位置）发送。
     • 例如，一个位于北京的用户请求一张网页上的图片，而这张图片已经被缓存到了北京当地的CDN节点中，那么这个节点就可以直接把图片发送给用户，避免了从可能位于美国的源服务器获取图片而产生的较长的传输延迟。
   • 缓存更新阶段
     • 如果CDN节点的缓存中没有用户请求的内容，它会从源服务器获取该内容。在获取内容后，它会将内容缓存到自己的服务器中，以便将来其他用户请求相同内容时可以直接从缓存中提供。
     • 同时，CDN系统会根据一定的缓存策略来管理缓存内容的更新。例如，根据内容的更新频率、用户请求的热度等因素来决定何时从源服务器重新获取更新后的内容。对于一些更新频繁的内容，如新闻网站的新闻稿，CDN可能会频繁地检查源服务器以获取最新内容；而对于一些相对稳定的内容，如网站的logo图片，缓存的更新周期可能会更长。
3. CDN的优势
   • 加速内容传输
     • 由于CDN能够将内容缓存到离用户较近的节点，减少了数据传输的延迟，从而大大提高了网页和资源的加载速度。这对于提升用户体验非常重要，特别是对于一些包含大量图片、视频等资源的网站。例如，对于一个电商网站，快速加载的商品图片可以让用户更快地浏览商品，增加购买的可能性。
   • 减轻源服务器压力
     • 大量用户请求可以由CDN节点来分担，而不是全部集中在源服务器上。这就像在源服务器前面设置了一道缓冲带，使得源服务器只需要处理CDN节点无法提供的内容请求（如尚未缓存的新内容或已过期的缓存内容）。例如，一个热门的视频网站，如果没有CDN，所有用户观看视频的请求都直接指向源服务器，源服务器可能会因为不堪重负而出现性能问题甚至崩溃；而有了CDN，大部分视频播放请求可以由CDN节点来处理，减轻了源服务器的压力。
   • 提高网站的可用性和稳定性
     • 即使源服务器出现短暂的故障或网络拥塞，CDN节点仍然可以提供部分缓存的内容，使得网站在一定程度上能够继续正常运行。例如，在遇到网络攻击或者源服务器维护期间，CDN缓存的内容可以继续服务用户，减少网站停机时间。

深浅克隆以及特殊应用

1. 深克隆和浅克隆的定义
   • 浅克隆
     • 浅克隆是指创建一个新对象，这个新对象的属性值是原始对象属性值的引用。简单来说，对于基本数据类型（如数字、字符串、布尔值）的属性，会进行复制；而对于引用数据类型（如对象、数组）的属性，只是复制了引用，新对象和原始对象的引用类型属性指向相同的内存地址。
     • 例如，有一个对象originalObject = {name: "John", hobbies: ["reading", "swimming"]}，对其进行浅克隆后得到clonedObject，clonedObject.name是一个新的字符串副本，但是clonedObject.hobbies和originalObject.hobbies指向相同的数组。
   • 深克隆
     • 深克隆是指创建一个新对象，这个新对象的所有属性（包括引用数据类型的属性）都是原始对象对应属性的完全复制。新对象和原始对象的引用类型属性在内存中是完全独立的，修改其中一个对象的引用类型属性不会影响另一个对象。
     • 例如，对于上面的originalObject进行深克隆得到deepClonedObject，那么deepClonedObject.hobbies是一个全新的数组，它和originalObject.hobbies在内存中是不同的，修改deepClonedObject.hobbies不会影响originalObject.hobbies。
2. 应用场景
   • 浅克隆应用场景
     • 部分数据共享场景：当需要在多个对象之间共享部分数据结构，同时又希望基本数据类型的属性是独立的时候，浅克隆很有用。例如，在一个图形绘制应用中，有多个图形对象可能共享同一个颜色对象（引用类型），因为颜色的改变通常是统一的，而每个图形对象的位置（基本数据类型）是独立的。
     • 性能优化场景：在一些对性能要求较高，且确定引用类型属性不需要深度复制的情况下，浅克隆可以节省内存和时间。比如，在一个简单的日志记录系统中，只需要记录一些基本信息和对某个大型数据结构（如配置对象）的引用，不需要对这个大型数据结构进行完全复制。
   • 深克隆应用场景
     • 数据隔离场景：当需要完全独立地处理数据副本，避免原始数据受到任何影响时，深克隆是必要的。例如，在一个多用户协作的文档编辑系统中，当一个用户对文档进行修改时，需要对原始文档进行深克隆，使得每个用户的修改操作都在独立的文档副本上进行，不会相互干扰。
     • 复杂对象持久化场景：在将对象存储到数据库或者进行数据传输时，为了避免对象的引用关系导致的数据不一致问题，需要对对象进行深克隆。比如，将一个包含多个嵌套对象的复杂业务对象序列化为JSON格式进行网络传输，就需要深克隆这个对象，以确保接收方得到的是一个完整且独立的副本。
3. 应用方式
   • 浅克隆应用方式
     • 对象展开语法（ES6+）：对于简单的对象，可以使用对象展开语法进行浅克隆。例如，const clonedObject = {...originalObject};。这种方法在JavaScript中非常方便，适用于不包含复杂引用类型嵌套的对象。
     • Object.assign()方法（ES6+）：可以使用Object.assign()来实现浅克隆。例如，const clonedObject = Object.assign({}, originalObject);。它将originalObject的可枚举属性复制到一个新的空对象中，对于引用类型属性只是复制了引用。
   • 深克隆应用方式
     • JSON序列化和反序列化（有局限性）：在JavaScript中，可以先将对象转换为JSON字符串，然后再将JSON字符串转换回对象来实现深克隆。例如，const deepClonedObject = JSON.parse(JSON.stringify(originalObject));。但是这种方法有局限性，它不能处理函数、循环引用等特殊情况。
     • 递归克隆（自定义函数）：可以编写一个自定义的递归函数来实现深克隆。以下是一个简单的JavaScript示例，用于克隆一个包含对象和数组的复杂对象：

     function deepClone(obj) {
         if (typeof obj === "object" && obj!== null) {
             if (Array.isArray(obj)) {
                 return obj.map(item => deepClone(item));
             } else {
                 let newObj = {};
                 for (let key in obj) {
                     newObj[key] = deepClone(obj[key]);
                 }
                 return newObj;
             }
         } else {
             return obj;
         }
     }
     

     • 这个函数首先判断obj是否为对象类型（数组也是对象），如果是，对于数组类型，使用map函数递归地克隆每个元素；对于普通对象，使用for...in循环递归地克隆每个属性。如果obj不是对象类型，则直接返回obj。

     函数克隆实例

     1. 理解对象中函数克隆的难点
   • 当克隆包含函数的对象时，简单的递归克隆（如只处理对象和数组的递归克隆）无法正确复制函数。因为函数在JavaScript中是一等公民，它有自己的作用域和上下文。如果只是简单地复制函数引用，那么新对象和原始对象中的函数将共享相同的函数体，这可能导致意外的行为。而且，如果想要完全独立的副本，需要考虑函数内部的this指针、闭包引用等因素。
4. 使用eval()函数（有风险）的克隆方法
   • 一种不太安全但可能有效的方法是使用eval()函数来处理函数克隆。例如，假设我们有一个对象originalObject，其中包含函数：

   const originalObject = {
       property1: "value1",
       myFunction: function() {
           return this.property1;
       }
   };
   

   • 可以尝试以下克隆方法：

   function cloneObjectWithFunction(obj) {
       let newObj = {};
       for (let key in obj) {
           if (typeof obj[key] === "function") {
               newObj[key] = eval('(' + obj[key].toString() + ')');
           } else {
               newObj[key] = obj[key];
           }
       }
       return newObj;
   }
   

   • 这个函数cloneObjectWithFunction遍历原始对象obj的每个属性。当遇到函数属性时，它将函数转换为字符串（使用toString()），然后通过eval()函数将字符串重新解析为函数，并将其赋值给新对象newObj的相应属性。这种方法的风险在于eval()函数会执行任意JavaScript代码，如果原始函数中包含恶意代码或者意外的代码，可能会导致安全问题。
5. 更安全的构造函数克隆方法
   • 如果对象中的函数是通过构造函数创建的，可以使用构造函数来克隆函数。假设我们有一个构造函数MyObject，其中包含一个方法：

   function MyObject() {
       this.property1 = "value1";
       this.myFunction = function() {
           return this.property1;
       };
   }
   

   • 可以这样克隆包含这个函数的对象：

   function cloneObjectWithFunction(obj) {
       if (obj instanceof MyObject) {
           let newObj = new MyObject();
           for (let key in obj) {
               if (typeof obj[key] === "function") {
                   newObj[key] = obj[key].bind(newObj);
               } else {
                   newObj[key] = obj[key];
               }
           }
           return newObj;
       } else {
           // 非MyObject类型的对象克隆方法（如之前的递归克隆）
           let newObj = {};
           for (let key in obj) {
               if (typeof obj[key] === "function") {
                   newObj[key] = eval('(' + obj[key].toString() + ')');
               } else {
                   newObj[key] = obj[key];
               }
           }
           return newObj;
       }
   }
   

   • 在这个方法中，当确定对象是MyObject的实例时，首先使用new MyObject()创建一个新的对象。然后对于函数属性，使用bind()方法将函数的this指针绑定到新对象上，这样新对象中的函数就有了独立的this上下文。对于非MyObject类型的对象，仍然使用之前带有eval()的方法（这种方法虽然有风险，但在某些情况下可能是必要的）。
6. 使用Function.prototype.bind()和Function.prototype.call()组合的方法
   • 假设原始对象originalObject有一个函数属性myFunction，可以这样克隆函数：

   function cloneObjectWithFunction(obj) {
       let newObj = {};
       for (let key in obj) {
           if (typeof obj[key] === "function") {
               newObj[key] = function() {
                   return obj[key].call(newObj);
               };
           } else {
               newObj[key] = obj[key];
           }
       }
       return newObj;
   }
   

   • 这种方法通过call()函数在新对象的上下文中调用原始函数，从而创建了一个新的函数，这个新函数在执行时会使用新对象的this上下文，实现了函数的克隆。不过这种方法对于函数内部使用this指针的情况需要谨慎处理，确保this指向符合预期。

JWT 鉴权

1. JWT（JSON Web Token）简介

   • JWT是一种开放标准（RFC 7519），用于在各方之间安全地传输信息。它以紧凑、自包含的方式将信息编码为JSON对象。JWT主要由三部分组成：头部（Header）、载荷（Payload）和签名（Signature）。
   • 头部（Header）：通常包含两部分内容，令牌的类型（通常是JWT）和所使用的签名算法（如HMAC SHA256、RSA等）。例如，{"typ": "JWT", "alg": "HS256"}，这个头部信息会经过Base64编码后成为JWT的第一部分。
   • 载荷（Payload）：这是JWT中存放有效信息的部分，包含了一些声明（Claims）。这些声明可以是标准的（如iss - 签发者、exp - 过期时间、sub - 主题等），也可以是自定义的。例如，{"sub": "1234567890", "name": "John Doe", "admin": true}，这些信息也会经过Base64编码，成为JWT的第二部分。
   • 签名（Signature）：签名是为了保证JWT的完整性和真实性。它是通过将头部和载荷的Base64编码后的内容，再结合一个密钥，使用头部中指定的签名算法生成的。例如，使用HS256算法，签名的计算方式为HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)。

2. JWT鉴权的原理

   • 生成令牌（Token）：当用户成功登录（或者经过其他认证方式）后，认证服务器会生成一个JWT。这个JWT包含了用户的相关信息（如用户ID、角色等）以及过期时间等。例如，一个用户登录到一个Web应用，认证服务器验证用户凭据后，生成一个JWT，其中载荷部分可能包含用户的ID和角色（如{"sub": "user123", "role": "admin"}）。
   • 传输令牌（Token）：生成的JWT会被发送给客户端（通常是浏览器），客户端会将这个JWT存储起来，一般存储在localStorage或者cookie中。之后，客户端在每次请求需要授权的资源时，会将JWT包含在请求头（通常是Authorization头，格式为Bearer <token>）中发送给服务器。
   • 服务器验证（Verification）：服务器收到带有JWT的请求后，首先会提取JWT。然后，它会验证JWT的签名，通过使用相同的签名算法和密钥来验证签名是否正确。如果签名正确，说明JWT在传输过程中没有被篡改。接着，服务器会检查JWT的过期时间（如果有）以及其他声明（如角色声明），以确定用户是否有权访问请求的资源。例如，如果一个资源需要admin角色才能访问，服务器会检查JWT中的角色声明是否为admin。

3. JWT鉴权的优势

   • 无状态性（Stateless）：与传统的基于会话（Session）的鉴权方式不同，JWT鉴权是无状态的。服务器不需要存储会话信息，减轻了服务器的存储负担。每次验证只需要验证JWT本身的有效性，而不需要查询数据库或者其他存储介质中的会话记录。这使得服务器更容易进行水平扩展，因为不需要在多个服务器之间同步会话状态。
   • 跨平台和跨语言支持：JWT是一种基于JSON的标准，几乎所有的编程语言都有相应的库来生成和验证JWT。这使得它非常适合用于跨平台和跨语言的应用场景。例如，一个Web应用的后端使用Python，前端使用JavaScript，它们可以很容易地通过JWT进行鉴权通信。
   • 可扩展性（Scalability）：由于JWT的无状态性和标准化，它可以很容易地集成到微服务架构中。不同的微服务可以独立地验证JWT，而不需要共享会话状态。这有助于构建更加灵活和可扩展的系统。

4. JWT鉴权可能遇到的问题及解决方案

   • 密钥管理问题：JWT的签名依赖于密钥，如果密钥泄露，攻击者就可以伪造JWT。因此，密钥的管理非常重要。解决方案包括定期更换密钥、使用安全的密钥存储方式（如硬件安全模块 - HSM）等。
   • 过期时间设置问题：如果JWT的过期时间设置过长，可能会增加安全风险；如果设置过短，又会导致用户频繁登录。可以根据应用的具体需求（如用户活跃度、安全性要求等）合理设置过期时间，也可以采用刷新令牌（Refresh Token）的机制。刷新令牌可以在JWT快要过期时，用于获取新的JWT，而不需要用户重新登录。
   • 信息篡改问题：虽然JWT的签名可以防止信息篡改，但如果签名算法存在漏洞或者攻击者能够获取密钥，就可能出现信息篡改的情况。需要使用安全的签名算法（如HS256、RS256等），并且定期更新签名算法和密钥来降低风险。

token 放在url中行否

1. 可以放在URL中的情况及原因

   • 便利性和兼容性（在某些特定场景下）
     • 在一些古老的浏览器或者对安全性要求相对较低的简单Web应用中，将Token放在URL中是一种可行的临时解决方案。例如，在一些简单的本地测试环境或者小型内部工具应用中，开发者可能会这样做来快速实现功能，尤其是当他们主要关注功能实现而不是最佳安全实践时。这种方式对于简单的概念验证（POC）项目或者快速原型开发也可能是有用的，因为它相对容易实现，不需要复杂的请求头设置或者存储机制。
   • 跨域请求（部分场景）
     • 在跨域资源共享（CORS）的场景中，当无法通过标准的请求头（如Authorization头）来传递Token，且服务器允许这种方式的情况下，将Token放在URL中可以作为一种替代方案。不过，这种情况比较少见，并且通常需要对服务器进行特殊配置，以接受和验证URL中的Token。例如，在一些旧的或特殊的服务器设置中，可能会允许通过?token=<token - value>这样的方式来接收和验证访问权限。

2. 不建议放在URL中的原因

   • 安全风险
     • 日志记录风险：服务器通常会记录URL访问日志，当Token放在URL中时，Token就会被记录在服务器日志中。如果服务器日志被泄露或者被未授权的人员访问，Token就会暴露，从而导致安全漏洞。例如，一个包含用户认证Token的URL被记录在日志中，攻击者获取日志后，就可以利用这个Token来冒充用户进行非法访问。
     • 浏览器历史记录和缓存风险：浏览器会存储访问过的URL，并且可能会缓存页面。如果Token在URL中，它就会存储在浏览器历史记录和缓存中。这样，通过访问浏览器历史记录或者在缓存中查找，就有可能获取Token。例如，在一个共享的计算机环境中，其他用户可能会通过查看浏览器历史记录获取包含Token的URL，进而获取访问权限。
     • Referer头泄露风险：当浏览器发送请求时，会自动包含Referer头，它会显示请求的来源URL。如果Token在URL中，这个Referer头就可能会将Token泄露给其他网站。例如，当用户从一个包含Token的页面点击链接访问另一个网站时，Referer头就会将带有Token的原始URL发送给新网站，新网站可能会恶意收集这些信息。
   • 维护和兼容性问题
     • URL长度限制：URL有一定的长度限制，不同的浏览器和服务器对URL长度的限制各不相同。如果Token很长，加上其他请求参数后，可能会导致URL超过长度限制，从而导致请求失败。例如，一些复杂的JWT（JSON Web Token）可能会很长，当放在URL中时，很容易超出长度限制。
     • 代码维护复杂性：将Token放在URL中会使代码的维护变得复杂。因为需要在多个地方处理URL中的Token，包括构建请求、解析请求等。与使用标准的请求头传递Token相比，这种方式更容易出错，并且不符合常见的安全和编程最佳实践。例如，在更新或修改鉴权逻辑时，需要考虑对URL中Token处理方式的影响，而使用请求头方式相对更加简洁和统一。