编程

一些大模型翻车现场的参考网站 https://enaih.org/ https://failureindex.ai/ https://incidentdatabase.ai/ DeepSeek 2026.09.08 要求绘制网页解释KMP算法的LPS算法时，出现逻辑错误 deepseek对此错误的解释： 本质局限：Token预测 vs 逻辑推理 我是"下一个词预测器"，不是"代码执行器"。生成描述时基于统计模式，而非实际运行代码。 注意力局部化 聚焦在 p[i] != p[j] 这个条件本身，忽略了 j=0 时的特殊上下文（此时 p[0]=‘A’ 与 p[2]=‘A’ 实际相等）。 训练数据偏差 “不匹配→j保持0” 是训练数据中的高频模式，我的概率分布倾向于套用这个"常见模板"，即使当前状态实际是匹配。 缺乏执行验证 没有"在脑中真正运行代码"的能力，生成后没有自动检查：if (j===0 && p[i]===p[0]) 应生成"匹配"描述。 根本矛盾 我是统计学家，不是计算机。统计数据模式可以，精确执行状态转换不行。 2026.09.10 SQL题目自己改了原题 要求算出最高分、和平均分，自己却认为还要算出最低分

Java：==、equals() 与 hashCode()（HashMap） 我的理解偏差 把 == 只理解成“比较引用地址” 这只适用于引用类型。 对基本数据类型，== 比较的是值。 对引用类型，== 判断两个引用是否指向同一个对象。 把 equals() 说成“判断是不是同一个对象” 更准确的说法是：equals() 用于判断两个对象是否“逻辑相等”。 两个不同的对象，也完全可以因为业务字段相同而 equals() == true。 把 hashCode() 理解成可以直接定位到某个对象 hashCode() 主要用于散列查找，帮助 HashMap 快速缩小查找范围、定位桶。 不同对象可能拥有相同的 hashCode，因此 hashCode 不能唯一确定一个对象。 HashMap 找到桶后，还需要通过 equals() 进一步确认 key。 “重写 equals 必须重写 hashCode”的关键原因没有说完整 Java 约定：如果 a.equals(b) == true，则必须保证 a.hashCode() == b.hashCode()。 在 HashMap 中，如果两个逻辑相等的 key 因为 hashCode 不同被定位到不同的桶，那么查找时连 equals() 都可能没有机会执行，最终导致本应相等的 key 查找失败。 核心记忆 hashCode() 负责“找桶”，equals() 负责“认人”。 如果 equals() 相等但 hashCode() 不同，两者可能被放进不同的桶，甚至没有机会进行 equals() 比较。 ...

从基础理论到体系结构与工程实践：按类别探索 240 个技术难点，用箭头发现知识之间的关系，并在本地记录学习进度。

本文记录一台实际 Windows 11 主机的排障过程。它不是“所有 TUN 蓝屏都这样修”的万能答案；核心方法是：先读转储确认致错驱动，再只改与证据相符的一段网络链路。 结论先说 这次蓝屏并不是 Wintun 本体直接崩溃，也不是“Clash 不兼容 Windows”。两个 0xD1 minidump 都落在相同的收包路径： rt640x64.sys (Realtek RTL8125B) → NDIS → tcpip / WFP → UDP → afd rt640x64.sys 是 Realtek 2.5GbE 网卡驱动。TUN 模式会显著增加转发和 UDP 收包压力，从而触发该驱动路径中的非法内存访问。处理方式是保留 Clash、Wintun、VMware 和 Hyper-V 配置，只针对物理网卡关闭有问题的 UDP 卸载与节能特性，再重启网卡验证。 本次已实施的修复 关闭 UDP IPv4/IPv6 Checksum Offload、Green Ethernet、Gigabit Lite、Power Saving Mode、Selective Suspend；有线网络重新连通，DNS、ICMP、HTTPS 均通过复测，修改后没有产生新的 BugCheck。 说人话就是 代理开启TUN之后，网络流量变多、路径更复杂，尤其是 UDP 包。 此时的 Realtek 网卡驱动 rt640x64.sys 在 “接收网络数据” 时出了差错，把坏数据交给了 Windows 网络系统。Windows发现内核内存可能写坏，只能立刻蓝屏自保。 解决的方案：关闭了网卡里容易出问题的“硬件加速收包”和省电功能。 为什么这个方案能解决问题？ ...

这些东西我没有一个是从书上看来的，全是踩过坑之后才明白为什么不能这么写。排名不分先后，纯粹是想到哪写到哪。 1. 只给ID，标题让前端自己一个个请求 场景很常见：前端要一个文章列表，后端图省事，GET /articles 只返回一堆 id，然后美其名曰"职责分离"——标题详情是另一个接口的事，你调 GET /articles/{id} 自己拼去。 结果就是列表页一进来，控制台里刷出几十个并发请求，首屏卡成PPT。这不是设计，这是把N+1查询问题原封不动甩给了前端，还顺便多绕了一层网络延迟。列表接口该把列表页需要的字段一次性拼好返回，这不是"过度设计"，这是接口的基本职责。 2. 全表返回，不做分页 “反正数据量不大”——这句话是很多线上事故的开场白。今天不大，半年后呢？没有分页参数的接口，就是埋了一颗定时炸弹，炸的时候往往连负责人自己都忘了当初为什么这么写。哪怕现在数据只有几百条，分页也该在设计阶段就加上，代价几乎为零，省下的是未来某次大促时数据库被一个"查全部"接口打满连接池的命。 3. 自增主键直接暴露给前端 /api/order/1001、/api/order/1002……这种URL我见一次难受一次。别人改个数字就能把你家订单量、用户增长速度、甚至竞品的下单节奏摸得一清二楚，运气不好还能顺便遍历出别人的订单详情。对外暴露的标识符该用UUID或者做一层编码，自增ID留在库里自己用就好，它不欠任何人一次直接曝光。 4. 异常堆栈原样甩给前端 线上环境返回500的时候，body里直接是一段完整的Java堆栈，类名、包路径、SQL语句全在里面——这种接口调试起来是挺爽，问题是生产环境不该有这种爽。这相当于把系统架构图直接发给了任何一个愿意多点几次的人。异常该在网关或全局异常处理器那一层被拦下来，转成一句用户能看懂、攻击者看不出细节的提示，详细堆栈老老实实进日志。 5. 事务里塞一个外部HTTP调用 有一次在 @Transactional 方法里调了一个第三方短信接口，那接口偶尔抽风延迟到十几秒。事务没提交完,数据库连接和行锁全程占着不撒手，一个接口卡住,连接池被排队请求瞬间打满，整个服务跟着一起趴下。外部调用和数据库事务从来不是一路人，该放事务外面的就老老实实放外面，实在需要保证一致性，用消息队列和补偿机制去做,别指望一个事务把所有环节焊死。 6. 用GET做有副作用的操作 GET /user/delete?id=1——这种接口写出来的时候可能只是图方便,浏览器插件预加载、爬虫、CDN缓存,随便一个都可能替你把"删除"这个动作提前执行了。GET的语义是幂等和无副作用，这不是规范洁癖，是因为整条链路上一堆中间层都会按这个假设去优化和缓存你的请求。有副作用的操作，POST/DELETE该用哪个用哪个,别为了省事挑软柿子捏。 7. 返回体里带着密码字段 哪怕只是加密后的密码,哪怕前端根本用不上这个字段,只要它出现在响应体里,就是多一次泄露的机会。抓包工具随手一看,一串哈希也可能被撞库反查出来。查询用户信息的DTO,该在序列化层面就把敏感字段挡掉,而不是寄希望于前端"不会去看"。 8. 循环里一条一条操作Redis或数据库 for 循环里挨个 redis.set()、挨个 insert，数据量小的时候看不出毛病，数据量一上来，网络往返的耗时全部线性叠加，接口响应时间跟着数据量一起爆炸。批量场景该用 pipeline、批量插入，这不是性能优化的"进阶技巧"，是写批量逻辑时候就该有的默认选项。 这几条共同的毛病，其实都是同一件事：图眼前方便，把成本转嫁给了未来的自己、前端同事，或者压根不认识的用户。后端接口设计里，“能跑"和"该这么设计"从来是两件事,分清楚这两者,大概就能避开清单里一半的坑。

我们为什么需要 MVCC ？ 没有MVCC（多版本并发控制 Multi-Version Concurrency Control）的情况下，面对数据库事务中"读某一条数据"的行为，我们只能加锁。这个锁可以是共享锁/排他锁，保证"我读的时候没人过来写"，避免脏读（读到和最终结果不一致的数据）。然而一旦加锁，其他线程就要等，一等并发效率就直线下降。 MVCC 的思路是：读的时候不加锁，而是通过"版本"来判断一条数据对我来说能不能读。 每一行数据的三个隐藏字段ba 每一条数据除了业务字段外，还有三个隐藏字段： DB_TRX_ID 最近一次插入/更新/删除该行的事务id DB_ROLL_PTR 回滚指针，指向这行数据在 undo log 中的上一个版本 DB_ROW_ID 隐藏主键，仅在表没有定义主键时才会生成 undo log 把同一行数据的历史版本串成一条链，DB_ROLL_PTR 就是链上的指针，出问题时可以顺着它一路往回找老版本。 Read View：读之前先拍个快照 在真正读数据之前，我们会先生成一个快照，叫做 read view。它记录了这几样东西： m_ids 生成快照那一刻，所有"活跃"（未提交）的事务id列表 min_trx_id m_ids 里最小的那个id max_trx_id 系统里下一个将要分配的事务id（也就是目前已知最大事务id + 1） 注意 max_trx_id 不是"当前活跃事务里最大的那个"，而是"还没被任何事务用过的、未来第一个可用的id"——因为事务id是全局递增分配的。 这里要先说清楚一件容易被忽略的事：read view 什么时候生成，在不同隔离级别下是不一样的。 READ COMMITTED（读已提交）：每次执行 SELECT 语句都重新生成一个 read view REPEATABLE READ（可重复读，MySQL默认）：只在事务内第一次执行 SELECT 时生成一次，之后整个事务复用同一个 read view 这个区别直接决定了"我这次读，能不能看到别人事务提交的新数据"——RC 每次都能看到最新提交的结果，RR 则始终锁定在事务开始时的那个快照上，这也是可重复读名字的由来。 拿到 read view 之后，怎么判断某一行能不能读 现在回到最初的问题：我们要读一行数据，它的 DB_TRX_ID = 200。这条数据被事务200修改过，我们能不能读到它，要按顺序做以下判断： ...

在我的项目“过家家”里，有一个抢红包的功能。功能类似微信抢红包。 抢红包的基本逻辑 v1（低并发）抢红包时实时使用二倍均值法计算，只使用MySQL 1. 红包创建流程 用户发红包时，指定总金额与红包个数 系统将总金额拆分为指定数量的红包 红包数量约束： 最少为 1 个 最多不能超过群成员数量 2. 红包金额分配策略 单个红包：不进行随机计算，抢到即获得全部金额 多个红包：采用二倍均值法进行随机分配 当前用户最大可抢金额 = 剩余金额 / 剩余人数 × 2 实际可抢区间为 [0.01, 最大可抢金额 - 0.01] 下限 0.01 元：保证每个抢到的用户都有收益 上限减 0.01 元：保证剩余红包仍有余额可抢 边际示例：10 元红包 2 人分，第 1 人可抢区间为 [0.01, 9.99] 3. 数据持久化与防刷控制 红包创建后入库存储 发红包限流：同一用户 10 秒内仅允许发送 1 个红包，防止手抖误操作 4. 抢红包并发控制 防重复抢：在 redpacket_grabs 表中建立 (userId, redpacketId) 联合唯一索引，确保同一用户对同一红包仅能抢一次 防超卖：采用数据库乐观锁机制 更新 redpacket 表时，必须同时满足： remaining_count > 0 remaining_amount >= 本次扣减金额 5. 方法缺点 每次请求直接打数据库，导致响应时间没有访问内存快 每次请求都会使用二分均值法计算抢到的金额，并且做超卖判断，比较麻烦 v2 （高并发）红包创建好了就已经固定了抢红包的数量和个数，加入Redis 大致流程 ...

偏移量索引 高可用 ISR机制