随笔分类 - 问题思考
摘要：“Data URL” 和 “Base64” 经常被混用，但它们不是同一概念，而是包含关系：Base64 是一种编码方式，Data URL 是一种 URI 格式，它可以使用 Base64 编码来嵌入数据。 下面从定义、结构、用途和区别四个方面清晰解释： ✅ 1. Base64 是什么？ 本质：一种将二
阅读全文
摘要：File.prototype.stream() 和 ReadableStream.getReader()，这是现代 Web Streams API 的一部分。 虽然功能强大（支持流式处理大文件、低内存占用），但它的浏览器兼容性比 file.arrayBuffer() 更晚，需谨慎评估目标环境。 ✅
阅读全文
摘要：File.prototype.arrayBuffer() 是现代浏览器中用于将 File（或 Blob）对象异步读取为 ArrayBuffer 的原生方法，相比传统的 FileReader.readAsArrayBuffer() 更简洁、基于 Promise，且性能更好。 ✅ 浏览器兼容性（截至 2
阅读全文
摘要：URL.createObjectURL(file) 与 FileReader.readAsDataURL(file) 都可用于在浏览器中生成本地文件的可访问 URL（例如用于图片/视频预览）， 但它们在实现机制、性能、内存占用和适用场景上有本质区别。以下是详细对比与最佳实践建议： 🔍 核心对比 特
阅读全文
摘要：系统地梳理一下 FileReader 的几种读取方式在本质区别、使用场景和性能表现上的差异： 📌 FileReader 四种主要读取方法对比 方法 返回值类型 适用场景 性能/注意事项 readAsText(file, encoding?) string 纯文本（如 .txt, .json, .c
阅读全文
摘要：除了 Access-Control-Allow-Origin，服务器通常还需要设置以下关键响应头来完整支持CORS： 必需头 Access-Control-Allow-Methods 定义允许的HTTP方法（如 GET, POST, PUT, DELETE, OPTIONS）。 示例：Access-
阅读全文
摘要：在标准 Web 安全策略下，前端无法直接修改 fetch 请求的 Origin 请求头。Origin 是由浏览器自动生成并添加的，其值由请求的协议、域名和端口决定，开发者无法通过 JavaScript 直接覆盖或修改。 关键限制： 浏览器控制：Origin 属于 禁止修改的请求头（forbidden
阅读全文
摘要：不一定。仅设置： add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always; 并不能保证预检请求（OPTIONS）会返回 200，原因如下： ❌ 问题核心：Nginx 默认不会处理 OPTIONS 请求 在 Nginx
阅读全文
摘要：浏览器跨域与同源策略 🔒 跨域问题源于浏览器的同源策略，目的是保障用户安全，脱离浏览器环境（如服务器间通信）不存在跨域 🌐 “同源”指两个 URL 的协议、域名、端口完全相同，路径不同不影响同源判断 ⚠️ 跨域请求仍会被发送至服务器并获得响应，但浏览器在校验响应头后若不通过（如缺少 CORS 头
阅读全文
摘要：浏览器在发送 跨域请求（CORS 请求） 时，某些特定条件下会先发送一个 预检请求（Preflight Request），这是一个 OPTIONS 方法的 HTTP 请求，用于询问服务器是否允许即将发送的实际请求。 ✅ 浏览器不会发送预检请求的情况（“简单请求”） 只有满足以下所有条件的请求才是 简
阅读全文
摘要：即使服务器设置了 Access-Control-Allow-Origin: *，浏览器仍报跨域错误，根本原因通常是：CORS 配置不完整 + 浏览器安全策略的严格校验。以下是高频原因与精准排查方案： 🔍 高频原因速查表（按发生概率排序） 排名 原因 浏览器典型报错关键词 解决方案 🥇 1 请求携
阅读全文
摘要：这是一个在前后端分离架构中非常常见的设计争议点。简单来说，这种“完全原子化”的设计有其合理性，但也带来了显著的前端开发复杂度，需要根据具体场景来评判是否“合理”。 下面我们从正反两面和最佳实践来详细分析。 一、为什么后端会这样设计？（合理性 / 优点） 接口复用性极高 每个接口只做一件事，功能纯粹。
阅读全文
摘要：在 JSDoc 中，@function 和 @description 是完全不同的两类标签，作用维度截然不同： ✅ 核心区别速览 标签 类型 作用 是否必需 典型位置 @function 结构标签（声明“这是什么”） 显式声明标识符为函数，解决解析器识别问题 ❌ 通常不需要（现代工具可自动识别） 注
阅读全文
摘要：在 JSDoc 中，@private、@protected、@public 和 @readonly 分属两个完全不同的控制维度，且标准性与工具支持差异显著。以下是精准对比： ✅ 核心区别总览表 标签 控制维度 标准性 作用 TS 关键字 是否互斥 典型场景 @private 访问权限 ✅ JSDoc
阅读全文
摘要：在 JSDoc 中，@constant 和 @readonly 都用于表示“值不可变”，但它们的语义、使用场景和官方推荐度有重要区别。以下是详细对比： ✅ 1. @readonly 官方状态：✅ 推荐使用（JSDoc 官方当前标准） 语义： 表示该成员初始化后不应被修改，强调“只读”行为。 典型使用
阅读全文
摘要：在 JSDoc 中，@link 和 @see 都用于引用其他相关项（如函数、类、外部资源等），但它们的用途、语义和渲染方式有明显区别。以下是详细对比： ✅ 1. @see —— “参见”：用于补充参考信息 作用：提供额外的参考资料，通常放在文档末尾作为“延伸阅读”。 内容：可以是： 其他函数/类的名
阅读全文
摘要：在 MSW（Mock Service Worker） 中，每个 request 对象本身并不是只能 await 一次，但你提到的疑问很可能源于对 Response 返回方式 或 流式响应（streaming） 的误解。下面详细解释： ✅ 核心结论 MSW 的 req（Request）对象可以被多次读
阅读全文
摘要：当前项目架构分析： 项目使用 pnpm workspace 管理 monorepo 有三个包：common（通用）、browser（浏览器专用）、node（Node.js专用） 每个包都是独立的 npm package，有自己的 package.json 当前三个包之间没有任何依赖关系，都是独立实现
阅读全文
摘要：遇到的错误： Error: Get Pages site failed. Please verify that the repository has Pages enabled and configured to build using GitHub Actions, or consider exp
阅读全文
摘要：开发一个 TypeScript + Monorepo 的前端工具函数类库，需要兼顾模块化、可维护性、类型安全、构建效率和开发者体验。以下是一个推荐的技术选型与目录结构设计方案： 一、技术选型 1. Monorepo 管理工具 推荐： pnpm + workspace 轻量、高效、支持软链接（hard
阅读全文
浙公网安备 33010602011771号