标题 Windows 双网络分流：公司 WiFi 走内网，手机 USB 共享走外网 副标题 / 摘要 你想访问公司内网（例如 192.168.x.x 的 Gitlab / 内部 API / 数据库），同时让浏览网页、下载等互联网流量走手机热点。 最稳的做法是：公司 WiFi 只负责内网，手机 USB 网络共享作为默认外网出口，并用 Windows 的路由优先级（跃点数/metric）把流量分开。 目标读者 需要访问公司内网服务，但不想让外网走公司出口的开发者/运维 经常在公司/外出之间切换网络，希望“插手机就能分流”的同学 Windows 10/11 用户（公司 WiFi + 手机 USB 共享） 背景 / 动机 当你同时连上： 公司 WiFi（内网：192.168.x.x） 手机 USB 网络共享（外网：互联网） Windows 会出现两个“默认网关”。如果不配置，系统可能随机抢路由，导致： 外网有时走公司（慢/受限） 内网有时走手机（根本不通） VPN/虚拟网卡（如 Tailscale、SSL VPN、WSL）插一条路由就更混乱 这篇文章的目标是把行为固定下来： 外网默认走手机 内网稳定走公司 WiFi 核心概念 默认路由（Default route）：0.0.0.0/0，没有更具体匹配时走它（通常就是“上网出口”）。 最长前缀匹配：越具体的网段路由优先（例如 192.168.1.0/24 会优先于 0.0.0.0/0）。 跃点数 / Metric：当有多条可用路径时，Windows 选择 metric 更小 的那条。 接口跃点数（Interface metric）：网卡层面的优先级，影响默认路由选择。 静态路由（Static route）：手动指定某个网段必须走哪个网关（可选但更稳）。 A — Algorithm（题目与算法） 题目还原 电脑连接公司 WiFi（只负责访问公司内网），手机用 USB 网络共享（只负责上互联网），怎么配置才能稳定分流？ ...

标题 WireGuard Split Tunnel 实战：手机热点上外网，同时访问公司内网 副标题 / 摘要 你想在外网（手机热点）正常上网，同时访问公司内网（192.168.x.x）服务。 最干净的方式是：外网默认走手机热点，只有内网网段走 WireGuard（Split Tunnel）。 目标读者 需要在外网访问公司内网服务（Gitlab/内部 API/数据库）的开发者 公司内网没有官方 VPN，或现有 VPN 体验差 希望“分流”：外网不走公司出口，内网安全可控 背景 / 动机 很多公司内网服务只在私网开放（如 192.168.1.0/24）。 当你在外面用手机热点上网时： 外网访问没问题 但内网地址不可达 如果你把电脑同时连两条网络（公司 WiFi + 手机热点），“能用但不干净”： 路由/DNS 冲突、稳定性差、切换成本高。 WireGuard 的价值在于： 只打通你需要的内网网段（Split Tunnel） 外网仍走你自己的手机出口 连接快、配置简单、性能好 核心概念 WireGuard：现代 VPN 协议与实现，配置简洁、性能优秀。 Peer：对端节点（客户端/服务器）。 AllowedIPs（关键）：决定哪些流量走 VPN。 Split Tunnel（分流）：AllowedIPs 只写内网网段，不接管默认路由。 NAT / 端口映射：服务器在内网（192.168.*）时，外网直连需要网关转发 UDP 端口。 思维推导（从“想要双网”到“正确分流”） 需求：公司内网访问 + 手机热点上外网。 朴素解：同时连两张网卡，靠系统自动选路由 → 不稳定。 关键观察：你的目标不是“同时连两张网”，而是“只让内网走公司通道”。 方法选择：WireGuard Split Tunnel：仅路由 192.168.x.x 走 VPN。 约束：WireGuard 需要一个外网可达的 Endpoint；如果公司服务器在 NAT 后面，需要端口映射或中转方案。 A — Algorithm（题目与算法） 题目还原 电脑连手机热点上网，但还能访问公司内网（如 192.168.1.0/24）。 ...

标题 Tailscale 子网路由实战：外网访问公司内网的最稳方案 副标题 / 摘要 当公司内网没有公网 IP 时，Tailscale 的子网路由是最省事、最稳定的方案。 本文给出完整的部署步骤、验证方法与排错清单，适合直接落地。 目标读者 需要在外网访问公司内网服务的开发者/运维 公司没有官方 VPN，且内网在 NAT 后面 希望实现“外网走手机热点、内网走 VPN”的分流需求 背景 / 动机 很多公司内网服务器只有 192.168.x.x 等私有地址， 外网无法直接访问，传统 WireGuard 需要公网 IP 或端口映射。 Tailscale 基于 WireGuard，但可以穿透 NAT， 无需公网入口即可实现安全访问，是更工程化的解法。 核心概念 子网路由（Subnet Router）：让一台内网机器“代理”整个内网段 Split Tunnel（分流）：只有内网流量走 VPN，外网流量不变 Advertise Routes：向 tailnet 宣告你能到达的内网网段 Approve Routes：在控制台批准路由才能生效 实践指南 / 步骤（完整落地） 以下以公司内网 192.168.1.0/24 为例，你可替换成自己的网段。 1）在公司内网服务器安装 Tailscale curl -fsSL https://tailscale.com/install.sh | sh sudo tailscale up 登录后，服务器会出现在控制台设备列表中。 2）将服务器设置为子网路由 sudo tailscale up --advertise-routes=192.168.1.0/24 3）到控制台批准路由（必须） 打开控制台： ...

标题 一台电脑同时连公司内网和手机外网：双网络分流实战 副标题 / 摘要 想用公司内网访问内部服务，又希望互联网走手机热点？ 本文给出 3 套可落地方案：USB 共享、双网卡分流、VPN Split Tunnel， 并提供 Windows/macOS/Linux 的实操步骤。 目标读者 需要访问公司内网，但不想走公司外网出口的开发者/运维 想在一个电脑上同时使用两条网络链路的技术人员 需要稳定分流、减少网络切换成本的同学 背景 / 动机 你希望达到的效果是： 公司内网服务（Gitlab、内网 API、数据库）走公司网络 外网互联网（搜索、下载、第三方服务）走手机热点 但普通电脑默认只能有一个默认网关， 所以要么全部走公司网，要么全部走手机网。 这也是需要“分流”的原因。 核心概念 网卡（NIC）：每条网络连接对应一个网卡（WiFi、USB、网线） 默认路由：系统不知道去哪就走默认网关 最长前缀匹配：更具体的网段路由会优先生效 分流（Split Routing / Split Tunnel）：内网走公司，外网走手机 实践指南 / 步骤 下面按稳定性从高到低给出三种方案： 方案 A：公司内网 WiFi + 手机 USB 共享（最稳定） 适用场景：只有一张 WiFi 网卡，想要最省事的分流方式。 连接公司 WiFi（内网） 手机开启 USB 共享网络，连接电脑 系统通常会把 USB 网络作为默认外网 优点：稳定、无需额外硬件； 缺点：需要 USB 连接手机。 方案 B：双 WiFi（USB 无线网卡） 适用场景：必须同时连接两个 WiFi。 ...

标题 请求日志一定要带 RequestId 吗？Python 成熟实践与落地指南 副标题 / 摘要 几乎所有“请求相关”的日志都应该带 requestId，但要通过自动注入而不是手工拼接。 本文给出 Python 成熟做法、工程场景与与 tracing 的关系，帮你真正落地。 目标读者 初学者：第一次处理线上问题，不懂为什么日志要串 requestId。 中级开发者：需要一套可复制的 Python 日志注入方案。 团队负责人：想建立统一的日志与追踪规范。 背景 / 动机 当系统出现错误时，最常见的现场是： “某个时间点报错了，但不知道是哪次请求导致的。” 如果所有“请求相关日志”都有 requestId，你就能一条链串起来： 从入口 → DB → RPC → 异常，一次请求的关键路径一眼可见。 在微服务/多进程环境里，requestId 更是日志协作的最低门槛。 核心概念 requestId：一次请求的唯一编号，用于日志串联与快速定位。 trace_id / span_id：分布式追踪中的链路标识（trace）与步骤标识（span）。 上下文传播：跨线程 / 协程 / 服务传递 requestId 或 trace。 自动注入：通过 middleware + logging filter，在日志里自动带 requestId。 思维推导（从朴素到工程可用） 朴素做法：每条日志手动写 request_id，很快遗漏、重复、维护成本高。 痛点暴露：一次请求会跨多个函数/协程/库层，手写方式不可控。 关键观察：requestId 本质是“请求上下文”，应由框架统一注入。 方法选择：在入口生成 requestId → 传入上下文 → logging 自动注入。 正确性理由：上下文随请求自然传播，日志格式统一且不侵入业务代码。 A — Algorithm（题目与算法） 题目还原 “是不是每一条日志都应该带 requestId？” ...

系统解释 Attention Is All You Need 的核心算法：自注意力、多头、位置编码与编码器-解码器结构，给出可运行示例与工程取舍。

解释 FlashAttention 在 MQA/GQA 下如何利用共享 KV：从数学等价（复制 KV）到工程收益（KV cache 与带宽），并给出可运行代码验证。

从标准注意力的显存 IO 账本出发，解释 FlashAttention 的核心：在线 softmax 维护 (m,l) 并流式累积输出，再配合 tiling 把数据驻留在片上存储，从而避免显式存储 $QK^\top$ 与 softmax 概率矩阵。本文给出可运行的 Numpy 分块注意力实现与数值等价验证，并用可复制的字节算账方法说明它为什么会快。

从标准两遍 softmax 的访存模式出发，推导在线 softmax（m,l）更新与正确性；进一步解释在 attention/cross-entropy 中如何通过融合避免落地概率矩阵，并用可运行代码验证等价与估算带宽收益。

副标题 / 摘要 Self-Attention 的公式很短，但工程细节很长：从 Q/K/V 计算到 softmax 数值稳定、mask 与缩放，每一步都影响效果与性能。本文用 ACERS 结构给出推导、实践步骤与可运行示例。 预计阅读时长：12~16 分钟 标签：attention、transformer、softmax SEO 关键词：Self-Attention, Softmax, Scaled Dot-Product, 数值稳定 元描述：Self-Attention 的计算公式与 softmax 稳定实现方法，含工程实践与示例代码。 目标读者 想真正理解 Self-Attention 公式含义的学习者 需要处理训练不稳定/溢出的工程实践者 关注注意力数值稳定与实现细节的开发者 背景 / 动机 在 Transformer 中，Self-Attention 是计算量最大、数值最敏感的模块之一。 很多训练不稳定、输出 NaN 的问题，都来自 softmax 的溢出/下溢或 mask 的错误处理。 理解公式与稳定实现，可以显著减少工程“踩坑”。 核心概念 Q/K/V：查询、键和值，来自输入线性投影 缩放点积注意力：$\text{softmax}(QK^\top/\sqrt{d_k})V$ 数值稳定：通过减去行最大值避免 softmax 溢出 思路推导（从朴素到稳定实现） 朴素做法 先算所有相似度 $S = QK^\top$，再做 softmax 得到权重 $P$，最后 $O = PV$。 这个实现最直观，但当 $S$ 很大时会出现 exp 溢出。 关键观察 softmax 对每行同时加上或减去一个常数不改变输出： $\text{softmax}(x) = \text{softmax}(x - \max(x))$。 ...