别着急，坐和放宽
摘要： 借助 Go 1.16 引入的 `go:embed` 指令，可以在编译期将文本、二进制文件、目录结构直接打包进可执行文件。对需要携带模板、静态资源、默认配置的 CLI 与 Web 服务而言，这显著简化了部署与文件加载流程，做到“一个二进制，跑遍环境”。
为什么选择 go:embed 编译期打包：资源在构建阶段入库，运行期无需磁盘依赖与路径探测。 原生 API：无需第三方库，标准库 embed、io/fs、net/http 即可使用。 一致的跨平台行为：统一使用正斜杠路径，避免 Windows/Unix 差异。 更安全可控：避免运行期“配置文件不在预期位置”导致的故障。 快速上手：单文件、目录与多文件 嵌入单个文本文件为字符串： `go package main import ( _ "embed" "fmt" ) //go:embed message.txt var message s...
为什么选择 SSE 面向“服务器→浏览器单向推送”的场景，浏览器原生支持 EventSource，无需第三方库 基于标准 HTTP（含 HTTP/2），与现有网关、负载均衡、鉴权、缓存体系兼容度高 自动断线重连与消息续传（Last‑Event‑ID）由浏览器内置完成 只需文本数据，天然适合通知、进度、日志、监控等单向推送 原理与协议 连接与建立 客户端通过 EventSource 发起 GET 请求，请求头隐式包含 Accept: text/event-stream；服务器以 Content-Type: text/event-stream 响应...
一、 深度剖析 Next.js 渲染模式 Next.js 的核心竞争力在于极其灵活的混合渲染机制。理解每种模式的 触发时机、数据流向 和 适用场景 是架构选型的基础。 1.1 渲染光谱 (The Rendering Spectrum) | 渲染模式 | 简述 | 构建/执行时机 | 数据新鲜度 | 典型场景 | | :--- | :--- | :--- | :--- | :--- | | SSG (Static Site Generation) | 纯静态生成 | npm run build 时 | 低 (下次构建前不变) | 营销页、文...
摘要： HTTP 协议演进史：从 0.9 到 3.0 的技术变革 HTTP (HyperText Transfer Protocol) 是万维网（World Wide Web）的数据通信基石。作为一名开发者，理解 HTTP 协议的演进过程，不仅能帮你更好地调试网络问题，还能让你在架构选型时做出更专业的决策。 本文将摒弃繁杂的比喻，从**技术痛点**与**解决方案**的角度，梳理 HTTP 协议的演进脉络。
一、 HTTP/0.9 & 1.0：协议的诞生与雏形 1. HTTP/0.9 (1991年) 设计初衷：极简的数据传输协议。 特征： 单行协议：请求只有一行，例如 GET /index.html。 无 Header：没有请求头和响应头。 仅限 HTML：服务器只能返回 HTML 格式的字符串。 连接模型：短连接。每次请求都需要建立 TCP 连接，响应结束后立即断开。 2. HTTP/1.0 (1996年) 随着互联网的发展，仅传输...
摘要： 在现代 Web 开发中，实时通信的需求无处不在：从即时通讯（IM）应用、在线游戏，到实时的股票行情、协作编辑文档。传统的 HTTP 协议在这些场景下显得力不从心，而 WebSocket 的出现彻底改变了这一局面。 本文将深入探讨 WebSocket 的核心概念、底层原理，并分别使用 TypeScript 和 Go 语言进行全栈实战，最后深入剖析 WebSocket 的鉴权机制。
1. 为什么我们需要 WebSocket？ 1.1 HTTP 的局限性 在 WebSocket 出现之前，为了实现“实时”效果，开发者们通常采用以下几种技术： 轮询 (Polling)：客户端每隔一段时间（如 1 秒）向服务器发送 HTTP 请求询问是否有新数据。 缺点：浪费带宽和服务器资源，大部分请求可能是空的。 长轮询 (Long Polling)：客户端发起请求，服务端挂起请求直到有数据才返回。 缺点：虽然减少了无效请求，但依然存在 HTTP 头部开销大、连接频繁建立释放的问题。此外，服务端需要长时...
摘要： Go 1.24 迎来了 Map 实现的历史性变革：正式弃用沿用十余年的“拉链法”，重构为基于 **Swiss Table** 的开放寻址架构。 本次升级的核心杀手锏是引入了 **SIMD 并行匹配**与**三角形探测算法**，将原本离散的内存布局转化为高度紧凑的连续存储。这不仅消除了溢出桶带来的指针跳转开销，更将负载因子从 81% 提升至 87.5%。对于开发者而言，这意味着在零代码改动的前提下，即可获得更低的内存占用与更强悍的查询性能。
1. 回顾过去：Go 1.23 以前的拉链法 1.1 核心结构 hmap：Map 的头节点，保存了 count、B、buckets 指针等。 bmap (Bucket)：每个桶固定存储 8 个键值对。为了内存对齐，它将 8 个 tophash 放在一起，接着是 8 个 key，最后是 8 个 value。 overflow：当桶满时，通过 overflow 指针挂载一个新的 bmap。 1.2 冲突与扩容 哈希冲突：使用拉链法。冲突的 Key 会被放入溢出桶中。 *...
摘要： 在爬取一些网站时经常会遇到Cloudflare自动化检测，playwright包处理此类验证码机制颇为繁琐，使用patchright可以有效遮蔽一些浏览器指纹的自动化检测机制，他的所有用法与playwright一致，可以无缝移植。
安装项目依赖 `shell python -m venv .venv source .venv/bin/activate pip install patchright pip install playwright_captcha 或使用 uv 安装 uv init demo uv install playwright_captcha uv install patchright #安装浏览器，当然你也可以不用安装 playwright 的浏览器，也可以使用系统自带的浏览器，通过 CDP 协议连接 (.venv) D:\Dev\Blog-demo\playwrig...
一、背景与起源 雪花算法(Snowflake)是Twitter开源的分布式ID生成算法，于2010年推出。在分布式系统中，我们经常需要生成全局唯一的ID，传统的数据库自增ID在分布式环境下会遇到性能瓶颈和单点故障问题。雪花算法应运而生，它能够在分布式环境下高效地生成趋势递增、全局唯一的64位长整型ID。 算法特点 全局唯一性：在分布式系统中保证ID不重复 趋势递增：生成的ID大致按时间递增，有利于数据库索引 高性能：本地生成，无需访问数据库或其他服务 高可用：不依赖第三方系统，可用性高 信息含量：ID中包含时间戳，...
一、为什么需要共识机制? 在去中心化的区块链网络中,没有一个"老大"来做决定。想象一下,如果100个人同时记账,怎么保证大家的账本是一致的?这就需要一套规则让所有人达成共识——这就是共识机制。 共识机制要解决的核心问题 1. 双花问题(Double Spending) 同一笔钱被花两次 就像用同一张支票在多个商店购物 2. 拜占庭将军问题(Byzantine Generals Problem) 如何在存在叛徒的情况下达成一致 区块链中即:如何防止恶意节点作恶 `mermaid graph TD A[区块链网络] -->...
一、 核心概念 1. 交易 分布式账本的参与者发生交易，导致账本状态的改变。 2. 区块（Block）： 区块是区块链中的基本单位，包含了一批已验证的交易数据。每个区块都有自己的唯一标识符和时间戳，并包含对前一个区块的引用，形成一个连续的链条 区块= 【块头】+【块体】 块头：头哈希（当前页哈希）+父哈希（上一页账单哈希），前一区块的交易信息压缩 主体：记录前一区块结束到该区块创建前所有交易信息 3. 区块链（Blockchain）： 区块链是一个被设计用来记录和验证交易的分布式账本系统。它由多个区块组成，每个区块包含一批...