Doraemon's Blog

如果你是一个科研工作者或者工科即将毕业的大学生，你应该会面临一个问题，AI 回答的公式复制到 word 后无法自动识别并转换，需要用光标一个个选中转换格式，网上提供的解决方案大多数是利用 mathtype+宏，但这样第一复杂，第二容易失败，第三速度慢，总之非常不方便，成本太高。那有没有一种办法可以让复制的公式一键转换为 word 公式呢，有的兄弟，使用我写的脚本，可以一键把剪切板的 latex 公式转化为 word 公式供你复制粘贴，非常方便，速度极快，仅需 1s。 有需要请联系我微信：HiSirGuo，只需一杯奶茶钱

如果你是一个开发者，或者是一个热衷于折腾 NAS 和树莓派的技术爱好者，你一定遇到过这个问题： “我在家里的局域网能用 SSH 连上我的服务器，但在公司或者出差时，怎么连都连不上。” 这时候，老手们会丢给你一个词：“做个内网穿透吧。” 这一篇博客将避开晦涩的教科书定义，面向有一定计算机基础的读者，从网络底层原理出发，讲清楚内网穿透到底穿的是什么“墙”，透的又是哪层“膜”。 为什么你“失联”了？在讨论如何“穿透”之前，我们必须先理解“阻隔”我们的是什么。 公网 IP 与 IPv4 的枯竭在互联网设计的最初愿景里，每一个设备都应该有一个全球唯一的 IP 地址（公网 IP）。如果大家都有公网 IP，根本不需要内网穿透，你只需要输入 ping 对方IP，就能直接握手。 但现实是残酷的：IPv4 地址只有约 43 亿个，早就被瓜分殆尽。 为了让全球几百亿台设备都能上网，工程师们发明了 NAT（Network Address Translation，网络地址转换） 技术。 NAT：路由器的“换皮”魔法 现在，运营商通常不会给你分配独立的公网 IP，而是把你划入一个巨大的局域网。你家里的路由器（ ...

用户特征是如何从文本变成我们所知的 embedding 向量的

下面这张图反映了2025 年我每个月的主线。 如果贯穿整年，主线任务只有一个：“求职”。从结果上看，还算是顺利地完成了这个主线任务吧，只是人心不足蛇吞象，如果拿年初我的求职目标来说，我应该是非常出色地完成了任务，甚至超出预期，但随着身边人一个个拿到了 BAT，拿到了 SSP，我也从最开始的过 40w 就行到了至少也得月薪 32k 起步吧，但不管怎么说，在工资待遇和业务方向上，我已经超越了绝大多数校招生，回顾这一年的求职历程，可谓一波三折。 从二月返校开始，我几乎把全部精力都投入到了求职之中，健身和约会的频率被大幅压缩，每日的学习强度也接近当初备战考研的状态。2 月中旬到 3 月底是集中寻找实习的阶段，实际上从去年暑假起我就已经开始准备后端实习了，只是我有一个明显的缺点——总想等一切都准备充分再出手（大概源于自己偏向求稳的性格），再加上上学期将近一半的精力放在了恋爱上，结果实习没找到，却找到了一个女朋友，也算是在人生大事上先完成了一项。找实习的那段时间格外煎熬，真正开始投递简历、参加面试后才发现，学校里形成的那套思维模式在职场中显得既低效又笨拙：企业更看重数据量化、可拓展性，以及短周期 ...

理论基础 MDP（马尔可夫模型）：当前状态只和前面一个状态有关，目的是为了简化学习过程，认为当前状态就包含了过去的信息。与之相对的就是非马尔可夫过程，认为当前状态和前面的所有状态有关。 POMDP（部分马尔可夫可观测决策模型）：POMDP 是一种智能体无法直接观测到真实状态的决策模型。虽然系统的内部状态 仍然满足马尔可夫性（这点很关键），但智能体获得的只是状态的部分信息（观测值），因此对智能体来说，环境表现为非马尔可夫的。 模型 场景比喻 MDP 你在明亮的房间里走迷宫，看得清周围墙壁的位置，决策只需看当前。 POMDP 你在黑暗中走迷宫，只能凭手电照到的一小块区域和脚步声猜测位置。环境本身仍遵守马尔可夫性，但你“看不全”。 状态价值函数：当智能体在状态 s 下，按照策略 π 行动后，能获得的期望总回报。公式：$V^\pi(s) = \mathbb{E}_\pi [G_t | S_t = s]$。 动作价值函数：当智能体在状态 s 下采取动作 a，然后再按照策略 π 行动，能获得的期望总回报。$Q^\pi(s, a) = \mathbb{E}_\pi [ ...

1. 进程上下文的总体分类一个进程的上下文主要分为三类： 用户级上下文（User-level Context） 内核级上下文（Kernel-level Context） 2. 各部分的内容（1）用户级上下文这是进程在用户态执行时的信息，主要包括： 用户虚拟地址空间（进程可访问的内存布局）： 代码段（Text Segment） → 存放程序的机器指令（只读） 数据段（Data Segment） → 存放全局变量、静态变量 BSS段（BSS Segment） → 存放未初始化的全局变量和静态变量 堆（Heap） → 动态分配（malloc/new） 共享库映射区 → 动态库、mmap 栈（Stack） → 函数调用、局部变量 用户栈内容（函数调用参数、返回地址、局部变量）。 用户态寄存器值（如 EAX、EBX、EIP、ESP 等）。 通用寄存器（AX、BX、CX、DX、RAX、RBX …）。 程序计数器 PC / 指令指针 IP（表示下一条将要执行的指令地址） 栈指针 SP（当前栈顶位 ...

为什么需要协程？ 高并发 I/O 场景：传统线程每创建一个都要占用较大内存（线程栈、内核数据结构等），当连接数达到数万、数十万时，线程开销和上下文切换代价太高。协程更轻量，可以同时管理大量并发任务（例如大量短暂的网络请求、文件 I/O）。 简化异步编程：用回同步风格（直线式代码）写异步逻辑，代码可读性好，容易维护。协程通过 suspend/await 等机制把异步逻辑写成像同步的流程。 更低的调度开销：协程通常在用户态由语言/运行时调度（或混合调度），上下文切换更快，资源消耗更小。 结构化并发：现代协程库支持“结构化并发”（父协程生命周期管理子协程），便于取消、超时和错误传播。 协程 vs 线程 —— 主要区别（要点） 调度层面：线程由操作系统调度（内核线程），协程通常由语言运行时/库在用户态调度（有的实现也支持把协程调度到多个内核线程上，比如 Go 的调度器或 Java 虚拟线程）。 创建/销毁成本：协程成本远小于线程（内存占用少、创建快）。 上下文切换：协程上下文切换开销小；线程上下文切换需要内核介入，代价大。 阻塞行为：线程阻塞只影响该线程；协程如果在单线程事件循环中执行阻塞操 ...

利用 Redis 的 SETNX 命令，SETNX 全称是 “SET if Not Exists”，意为仅当指定的键不存在时，才设置该键的值，多线程调用 SETNX 可以保证有一个线程可以执行成功。 有加锁就有解锁，解锁需要判断持有锁的是否是当前线程（避免释放错锁），然后再释放，这是两步操作，需要保证原子性，放在 LUA 脚本里。 释放错锁的例子：假设线程 A 持有锁，在锁未释放前因阻塞（如睡眠、网络延迟）超过锁的过期时间，锁被自动释放。此时线程 B 获取到该锁，若线程 A 恢复后直接解锁，会错误地释放线程 B 持有的锁，导致其他线程可能趁机抢占锁，引发并发安全问题（如数据不一致）。 分布式锁的 key 和 value 的设置也是有讲究的，针对不同的资源或业务场景，需要使用不同的 key。例如： 操作用户 A 的订单时，key 可以是 lock:order:1001（1001 为订单 ID）。 操作库存时，key 可以是 lock:stock:product:2002（2002 为商品 ID）。 value 标识 “持有锁的线程 / 客户端”，用于解锁时校验身份，防止误解锁（ ...

为什么需要分布式 ID？拿MySQL数据库举个栗子： 在我们业务数据量不大的时候，单库单表完全可以支撑现有业务，数据再大一点搞个MySQL主从同步读写分离也能对付。 但随着数据日渐增长，主从同步也扛不住了，就需要对数据库进行分库分表，但分库分表后需要有一个唯一ID来标识一条数据，数据库的自增ID显然不能满足需求，例如 user0 和 user1 两张表生成的 userid 如果采用自增 ID，会导致重复；特别一点的如订单、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。那么这个全局唯一ID就叫分布式ID。 那么分布式ID需要满足那些条件？ 全局唯一：必须保证ID是全局性唯一的，基本要求。 高性能：高可用低延时，ID生成响应要块，否则反倒会成为业务瓶颈。 高可用：100%的可用性是骗人的，但是也要无限接近于100%的可用性。 好接入：要秉着拿来即用的设计原则，在系统设计和实现上要尽可能的简单。 趋势递增：最好趋势递增，这个要求就得看具体业务场景了，一般不严格要求。 分布式 ID 的生成方案 UUID 数据库自增ID 数据库多主模式 号段模式 Redis ...

解决什么问题？我们都知道数据库可以通过事务来保证原子性操作，但实际场景中存在多个 DB实例或者微服务，例如扣减余额和扣减库存，如果余额和库存不在同一个 DB 实例中我们又该如何保证原子性操作？这就是分布式事务的概念。 首先需要铺垫一些理论： CAP 理论CAP 定理是分布式系统中的一个重要定理，它指出在一个分布式系统中，一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）这三个特性不能同时满足，最多只能满足其中两个。以下是对这三个特性的详细解释： 一致性（Consistency）：在分布式系统中，一致性指的是所有节点在同一时间具有相同的数据。也就是说，当一个数据在某个节点上被更新后，这个更新能够迅速传播到其他节点，使得所有节点都能看到最新的数据，就好像整个系统只有一个数据副本一样。例如，在一个分布式数据库中，如果一个用户在节点 A 上修改了一条记录，那么其他节点在查询该记录时，应该能够立即看到修改后的结果。 可用性（Availability）：可用性意味着系统中的每个请求都能得到响应，而不会出现长时间的等待或系统崩 ...