- 博客(84)
- 收藏
- 关注
原创 SQLite3 内存与缓存:cache_size、mmap_size、Pcache 与大数据集下的溢出诊断
SQLite内存管理主要涉及页缓存(Pcache)、工作区、临时结构和mmap映射区,所有操作都在应用进程地址空间完成。调优cache_size需考虑连接数、临时表、排序落盘和容器限额等因素。关键调优步骤包括:固定负载测试、监控缺页率/延迟、逐步增加缓存直至边际收益趋零。需注意mmap的虚拟内存占用风险、临时表溢出问题,并通过诊断RSS曲线、iostat等工具定位内存问题。大数据查询应限制返回列和使用游标。嵌入式设备需平衡缓存与OOM风险,将临时文件存储在耐用分区。SQLite内存优化需综合考虑连接模型、缓
2026-05-14 14:20:21
13
原创 SQLite3 碎片化监测与性能衰退:freelist、sqlite3_analyzer 与维护决策树
SQLite数据库碎片化治理摘要(149字) SQLite碎片化主要表现为空闲页堆积(freelist)、B-Tree页利用率下降和顺序读变随机。核心监控指标是freelist_count与page_count比值,建议超过15%且文件>500MB时评审维护。治理需分步:先排查慢查询、统计信息、索引问题,再考虑VACUUM操作。关键工具sqlite3_analyzer提供深度报告,但应在离线副本执行。建议建立三级预警机制(10%/20%/备份失败阈值),并将碎片指标与查询延迟、WAL体积等数据联动分析
2026-05-12 13:00:00
363
原创 多模态大模型「看图说话」之前在干什么?图文对齐与 VLM 结构入门
每一步数据配比失衡都会导致「会说但不会看图」或「过度保守拒答」。:视觉塔(CNN/ViT)抽图像向量,文本塔抽句子向量,投影到同一嵌入空间做对比学习(CLIP 路线思想)。在交互式助理里常见:先低分辨率定位 ROI,再高分辨率读细节。要做跨窗口位置编码或全局摘要 token,否则计数类任务会持续失败。(背景颜色与文本关键词偶然共现),而对精细空间关系、小字 OCR、计数任务不稳。噪声数据会让模型学会。提高输入分辨率改善 OCR 与细粒度计数,但激活图面积暴涨。对抗贴纸、二维码钓鱼图、隐写文本都能试探模型。
2026-05-12 07:30:00
426
原创 模型怎么「知道词在第几位」?绝对位置、相对位置与 RoPE 旋转编码在干什么
本文系统梳理了Transformer中位置编码的核心问题与主流方案。首先指出注意力机制本身具有置换不变性,必须通过位置编码引入顺序信息。早期可学习绝对位置向量存在外推问题,而正弦编码表达能力有限。当前主流方案RoPE通过旋转嵌入将相对位置信息融入注意力计算,兼具良好外推性和工程友好性。文章强调位置编码需与其他组件(如稀疏注意力)协同工作,并详细分析了RoPE的实现细节与排查要点,包括复数旋转机制、多尺度波长设计等。最后提醒实践中需严格匹配模型配置参数,避免因位置编码不当导致性能下降。位置编码虽关键,但长上下
2026-05-11 07:15:00
909
原创 「幻觉」到底是什么机制:参数记忆、训练目标与缓解路径(不实操玄学)
《大模型幻觉问题的工程应对策略》摘要: 本文系统分析了大模型产生幻觉的三大类型(事实错误、指令漂移、过度自信),指出其根源在于语言模型的概率匹配本质而非求真机制。作者提出分层解决方案:1)通过RAG外置可验证知识;2)利用工具调用外包可计算任务;3)设计输出约束机制(引用标注/拒绝策略)。强调领域应用中需区分创作与事实场景,建立监控指标闭环,并指出单纯扩大模型规模不如结构化输出控制有效。核心观点是:治理幻觉需前置验证流程,而非依赖事后模型自检。
2026-05-10 07:00:00
570
原创 Transformer 注意力机制到底在算什么?从 QKV 到 scaled dot-product 一文读懂
这篇文章简明扼要地解释了注意力机制的核心原理和实现细节。作者从基础概念入手,阐明注意力本质是位置间的相关性加权平均,而非神秘算法。重点解析了Q/K/V的来源与作用、缩放点积的数学原理、多头注意力的设计动机,并澄清了常见误解。文章特别强调工程实践中的关键点:维度变换的形状检查、softmax数值稳定性处理、KV缓存的推理优化,以及不同Transformer变体的层归一化位置差异。最后指出注意力虽强大但不是唯一序列建模方法,需要结合具体任务选择合适方案。全文以最小化数学符号的方式,将复杂机制还原为可操作的加权聚
2026-05-09 07:45:00
342
原创 504 Gateway Timeout 不一定是代码挂了:Nginx 代理超时与多层链路排查
摘要 HTTP 504 Gateway Timeout 通常是反向代理(如Nginx)在等待上游应用响应时超时导致的,而非业务逻辑错误。关键点包括: 504是代理层超时,与业务异常无关 默认60秒超时可配置,不同域名可能有不同设置 多层架构(CDN→Nginx→应用)每层都有独立超时策略 应对建议: 运维:调整正确层级的proxy_read_timeout 架构:对长任务改用异步方案 业务:拆分重计算请求 排查时需先确认504来源,再检查对应配置和链路各层日志。
2026-05-08 17:23:13
467
原创 让 AI 写单元测试:一套审查清单,专治「假绿」和无效断言
AI生成测试的常见陷阱与优化策略 摘要:AI生成的测试代码常存在三大问题:无效断言、虚假覆盖率和过度mock。通过10条检查清单可有效提升测试质量,包括确保每个测试有明确断言、覆盖失败路径、控制mock范围等。关键策略是AI起草+人工验收+CI验证,特别要注意断言的有效性和mock的适度性。对于算法边界和安全模块,建议人工编写测试。优化AI指令可显著提升生成质量,如明确要求覆盖各种输入路径和真实依赖层级。
2026-05-08 08:30:00
287
原创 什么是「AI 中转站」?一篇搞懂它在链路里的位置、用处和风险
AI中转站是指在用户应用与大模型服务之间增加的一层中间服务,主要用于统一接口、简化对接、提升网络可达性及密钥管理。常见形态包括纯转发代理、多模型路由、自建开源网关或商业服务。其核心优势在于简化运维,但也带来数据泄露、合规风险等问题。使用时需权衡数据敏感性、合规要求及团队能力,避免盲目依赖。建议优先服务端持有密钥,配置审计与逃生机制,确保业务灵活性。
2026-05-08 07:00:00
510
原创 SQLite3 ANALYZE 与统计维护:sqlite_stat1 / sqlite_stat4、过期症状与批量策略
SQLite统计表(sqlite_stat1/sqlite_stat4)是查询优化的核心,通过ANALYZE命令收集索引分布数据。大表分析可能耗时,建议在维护窗口执行。统计过期会导致性能下降,表现为全表扫描增多。维护策略包括:批量导入后分析特定表、周期性全库分析、结合VACUUM操作。对于大型数据库,可分表分批执行ANALYZE。统计维护应与数据变更同步,特别是在结构变更或大批量数据操作后。注意副本统计与主库的差异,避免直接复制统计文件。将ANALYZE纳入常规数据维护流程,比事后处理更高效。
2026-05-07 13:45:00
514
原创 用 git bisect 二分定位:到底是哪次提交把线上搞挂了
git bisect 是快速定位代码回归问题的二分查找工具。它通过标记「好」和「坏」提交,自动逐次验证中间版本,高效找到首个引入问题的提交。适用于能明确复现问题的场景(如测试失败、构建错误)。操作步骤包括标记边界、验证状态、自动化脚本执行,最终输出问题提交。相比手动排查或 git blame,它能显著减少调试时间,适用于开源和私有项目。关键在于准确定义「好/坏」边界,避免逻辑混乱。定位后可通过查看差异、提交 Issue 或考虑回滚解决问题。
2026-05-07 07:30:00
677
原创 SQLite3 VIEW 与「物化」模拟:普通视图、递归 CTE、报表场景与优化边界
SQLite中的视图与物化视图实践总结:普通视图是存储的查询文本,每次引用时展开优化;物化视图需通过物理表+定时刷新或临时表模拟实现。文章对比了持久视图与临时视图的适用场景,分析了视图对查询优化的影响,并介绍了递归CTE、物化视图模拟方案(快照表、触发器、应用缓存)以及复杂报表处理策略。特别强调视图维护需关注版本控制、单元测试、权限管理和查询优化验证,建议将关键SQL纳入版本管理。最终指出视图是查询复用工具而非性能解决方案,推荐采用执行计划分析+夜间快照表的稳健组合。
2026-05-06 14:00:00
450
原创 Conventional Commits + CHANGELOG:开源协作里怎么写提交与发版说明
约定式提交(Conventional Commits)和变更日志(CHANGELOG)是开源协作中高效沟通的核心工具。前者通过标准化提交格式(如feat/fix)明确代码变更意图,后者集中记录版本差异,解决用户升级时的关键问题(新增功能、修复缺陷、破坏性变更)。两者与语义化版本(SemVer)弱绑定,建议从手动维护开始,逐步引入自动化工具。关键原则:提交时预埋发版信息,CHANGELOG聚焦用户视角,避免维护者与贡献者因信息碎片化产生摩擦。
2026-05-06 06:30:00
369
原创 SQLite3 里 VACUUM 到底在干什么?何时用、怎么配、线上别踩这些坑
这篇文章详细介绍了SQLite数据库中VACUUM操作的实用指南。主要内容包括: VACUUM的作用是通过重建数据库文件来回收空间、减少碎片,但需要独占数据库且消耗额外磁盘空间。 适用场景:大量删除/更新后文件虚胖、发布前瘦身、迁移式整理。不适合高并发写入环境。 命令行操作方法和常见问题排查清单,包括文件大小查看、WAL模式下的注意事项等。 对比了auto_vacuum、incremental_vacuum和全量VACUUM的区别和使用策略。 特别强调了磁盘空间和锁机制这两个最容易出现问题的地方,以及如何在
2026-05-05 14:15:00
706
原创 第一次给开源项目提 PR:从 Fork 到合并的最小闭环(含被拒高频原因)
本文介绍了开源协作中提高首次PR成功率的实用指南。核心要点包括:1)准备工作需检查许可证和贡献规则,搜索相关Issue;2)操作流程应遵循Fork→Clone→建分支→小步提交→Push→开PR的标准化步骤;3)PR描述需包含清晰的动机、改动范围和验证方法;4)处理Review时要及时修改并推送更新;5)避免常见被拒原因如方向不符、大范围改动等。文章强调流程规范和沟通质量比代码完美更重要,掌握这些基础方法即可超越多数随意提交的贡献者。
2026-05-05 06:30:00
967
原创 OpenAI 兼容 API:多厂商模型切换时要懂的端点、密钥与限流常识
摘要 OpenAI兼容接口的核心工程要点在于配置清晰化和正确处理密钥与重试机制。开发者应重点关注:1) base_url的正确配置;2) 密钥轮转安全策略;3) 限流重试处理;4) 模型能力差异。密钥管理需遵循最小权限原则,避免泄露;限流处理应采用指数退避机制;切换模型时需核对上下文长度等关键参数。大团队可考虑自建API网关实现统一管理,但需确保安全配置。开发与生产环境可通过配置切换实现灵活部署。这些基础工程实践是保障系统稳定性的前提,应优先于模型选型和Prompt优化。
2026-05-04 15:45:00
394
原创 开源 Issue 怎么写「最小复现」:维护者愿意回的 MRE 清单
如何高效提交开源项目Issue? 本文总结了提交有效Issue的关键要点:首先确保问题可复现,提供完整环境信息(OS/版本/依赖);其次用最小复现(MRE)原则精简问题,删除无关代码;然后按模板结构化描述问题,包含复现步骤、期望与实际行为对比;避免提交无效信息如模糊描述或业务日志;注意不同社区对Issue/PR的要求差异;最后提醒注意安全,不要泄露密钥。核心是帮维护者快速定位问题,提高解决效率。 (字数:148)
2026-05-04 06:30:00
174
原创 MIT / Apache-2.0 / GPL:开发者选型时的工程向速查(非法律意见)
本文是一份开源许可证选择指南,从工程协作角度梳理了MIT、Apache-2.0和GPL三类常见许可证的核心差异。文章指出选择时需考虑三个关键问题:是否将代码用于闭源商业产品、是否关注专利授权条款、以及是否涉及衍生作品分发。MIT许可证适合希望最小化使用阻力的项目;Apache-2.0在保留宽松特性的同时增加了专利条款;GPL系列则具有"传染性",要求衍生作品保持开源。作者建议仓库至少包含LICENSE文件、README说明和第三方依赖检查,并强调复杂场景需咨询法务。最后提醒开发者,许可证
2026-05-03 07:30:00
339
原创 WebSocket 和 SSE 怎么选?实时通信入门与避坑
摘要:WebSocket与SSE是实时功能开发的两种主要方案。WebSocket适合双向高频交互(如IM聊天),SSE则更适合服务端单向推送(如AI输出流)。核心差异体现在协议基础、连接维护和实现复杂度上。上线需注意代理超时、重连机制、心跳缺失等问题。建议根据业务场景从简开始:优先SSE满足通知需求,必要时再升级为WebSocket实现双向交互。工程实践应遵循"够用原则",逐步演进而非过度设计。(149字)
2026-05-01 09:00:00
691
原创 线上问题总复现不了?TraceID + 结构化日志最小落地指南
摘要: 线上偶发Bug难修的核心问题是缺乏完整链路追踪。本文提供一套最小化改造方案:1) 为每个请求分配唯一traceId贯穿全链路;2) 采用JSON结构化日志输出。通过Node.js示例演示如何实现中间件级traceId透传、统一日志格式和请求耗时监控,并指出落地时需避免的四大坑点(如日志字段命名混乱、敏感信息泄露等)。该方案可在1周内上线,显著提升排障效率,使团队从"靠猜定位"进阶到"按链路追踪",为后续接入高级监控平台打下基础。
2026-04-30 20:26:53
923
原创 AI 改代码越改越乱?一套可落地护栏工作流
摘要: 本文针对AI辅助编程中的代码失控问题,提出了一套30分钟可落地的工程化解决方案。核心方法包括:1)需求锁定(明确修改范围/禁止项/验收标准);2)变更限幅(强制AI先输出改动计划);3)最小验证(静态检查+目标测试);4)小步提交(拆分commit保证可回滚)。文中提供了具体模板和7步验收清单,重点解决AI过度优化、边界不清、测试遗漏等常见痛点。通过设置清晰护栏,使AI从"随机重构"变为"精准提效",典型案例显示该方法可使接口优化风险降低80%以上。
2026-04-30 08:00:00
674
原创 ChatGPT 图像2.0发布:开发者最该关注的5个变化与上手清单
ChatGPT图像2.0升级核心在于提升生产效率和精准度,而非单纯的艺术表现。主要改进包括:1)复杂指令理解能力增强;2)图文排版更精准;3)多尺寸适配更稳定。对开发者最实用的场景是技术文章配图、UI草图和运营素材制作,通过结构化提示词可显著降低返工率。建议开发者建立场景化模板库,重点关注构图、文字清晰度和多尺寸适配,将AI作为高效的设计协作工具而非随机生成器。升级后的核心价值在于让图像生成更可控、更工程化,特别适合需要精确呈现文字和结构的应用场景。
2026-04-29 16:51:26
1060
原创 幂等性是什么?为什么会重复扣款,以及接口防重怎么做
摘要: 幂等性指同一操作执行多次对系统最终状态的影响一致,是分布式系统防重的关键。重复请求来源包括用户重试、客户端自动重试、消息投递等,需后端兜底。核心方案是幂等键(Idempotency-Key),配合Redis缓存结果与数据库唯一约束双重保障。实践需注意共享存储、事务一致性及回调处理,避免单实例失效或副作用。通过监控幂等命中率、冲突率等指标,可有效减少重复扣款等事故。落地原则是“请求可重复,结果仅生效一次”,结合幂等键与数据库约束实现双保险。
2026-04-29 14:00:00
672
原创 JWT 是什么?三段结构一次看清,别把「签名」当成「加密」
本文深入浅出解析JWT的核心机制与应用要点。JWT由Header、Payload、Signature三段组成,通过Base64URL编码形成可自描述的字符串。文章强调JWT的核心价值在于验证完整性而非保密性,Payload内容对持有者可见。详细解释了签名验证原理,指出JWT解决的是数据完整性和来源可信问题。针对常见误区,文章澄清了JWT与查库、安全性、长度限制等认知偏差,并建议敏感数据应避免放入token。最后通过Node.js示例演示JWT签发校验流程,强调实际应用中需结合HTTPS、过期策略等构建完整安
2026-04-29 07:30:00
1338
原创 for 循环里 setTimeout 为什么总是同一个值?从作用域到事件循环一次讲透
JavaScript中for循环与setTimeout结合时,使用var会导致输出重复的最终值(如5 5 5 5 5),而非预期的0 1 2 3 4。原因在于: var的函数作用域使所有回调共享同一个变量i; 同步代码先执行完(i已变为5),异步回调随后读取最终值。 解决方案: 首选let:块级作用域为每轮循环创建独立绑定; IIFE闭包:通过立即执行函数保存每轮的i值; setTimeout参数:直接传递当前值。 核心逻辑: 异步回调的执行时机与变量作用域共同决定输出结果,理解事件循环和变量绑定是
2026-04-28 08:00:00
405
原创 MCP 是什么?给开发者快速入门科普
MCP协议:AI工具集成的"USB-C接口" MCP(Model Context Protocol)是一种让AI系统与外部工具标准化对接的开源协议,如同电子设备的通用接口。其核心价值在于解决N×M的复杂集成问题,通过统一规范降低开发成本。 该协议采用客户端-服务器架构:客户端发起调用请求,服务器执行具体操作(如查询数据库、调用API等)。与Function Calling的关系是互补而非替代——MCP提供标准化接入层,Function Calling仍是底层机制。 适用场景: 需对接多工
2026-04-27 07:45:00
207
原创 Cursor 变慢怎么办?2026排查指南
如果你最近明显感觉 Cursor 变慢(AI 回复卡住、打字延迟、界面顿一下、启动变久),你不是个例。
2026-04-27 07:00:00
1434
原创 RAG 不准不是模型差:7个工程坑与可落地修复清单
摘要: RAG(检索增强生成)系统的准确率问题80%源于检索和评测链路,而非模型本身。文章从现象、原因到修复动作,提供了一份可落地的排查清单。首先将“不准”分为三类(未召回、召回但选错、生成错误),并建议分层指标评估。随后列举7个常见工程问题:切片策略错位、向量模型不匹配、纯向量检索缺陷、固定TopK、上下文拼接混乱、缺乏拒答策略及依赖主观反馈。最后给出短期(1-2周)和长期(1-2月)优化建议,强调RAG的核心是“基于正确证据生成答案”,需系统性拆解召回、排序、生成与评测环节。(150字)
2026-04-26 07:30:00
332
原创 别再只卷 Prompt:给 AI Agent 做一个可落地的反馈系统
本文提出AI Agent开发应建立反馈系统而非仅优化prompt,并给出最小闭环方案:定义任务标准→记录执行结果→自动评估打分→策略迭代更新。核心模块包括任务定义、日志记录、自动评估和策略更新,强调评估可复现和策略可回滚。文章指出常见误区如标准多变、变量混杂等,建议开发者从30条样本基线开始,逐步建立评估体系。作者认为持续的反馈机制比精致的prompt更能提升Agent性能,是构建AI系统的关键护城河。
2026-04-25 07:30:00
459
原创 GPT-5.5 昨日发布后,开发者该不该切?一份可执行迁移评估指南
本文针对GPT-5.5发布提出了一套可执行的迁移决策框架。首先分析了官方确认的核心升级点:强化多步骤任务能力、1M上下文窗口和更高定价。建议开发者重点关注长任务稳定性、上下文实际收益和单位业务价值三个维度。提供了一套"7天迁移法":从双模型盲测到业务成本核算,最后分层灰度上线。指出Agent编排、复杂工作流等场景应优先尝试,而简单任务可暂缓。特别提醒要避免全量切换、滥用长上下文等常见误区。最终结论是:GPT-5.5的核心价值在于成为"可交付的工作代理",而非单纯的聊天
2026-04-24 19:24:52
763
原创 大模型到底在算什么?用「猜下一个词」把 LLM 讲清楚
本文简明介绍了大语言模型(LLM)的核心工作机制。关键点包括:1)LLM本质是通过概率预测下一个token(词片)来完成文本生成,而非检索答案;2)采用自回归方式逐token生成内容;3)存在上下文窗口限制;4)温度和top-p参数控制生成多样性;5)幻觉源于概率性补全机制。对开发者的建议是:将其视为生成器而非真理机,合理管理上下文资源,并预期输出的随机性。理解LLM是"在给定上下文中合理接续文本"这一本质,有助于更好地应用相关技术。
2026-04-24 08:44:51
317
原创 哈希表(HashMap)为什么快?从原理到手写最小实现
本文系统讲解了哈希表的核心原理与应用要点。首先揭示哈希表本质是"数组+索引计算",通过哈希函数将查找操作从遍历比较优化为直接定位。文章详细分析了哈希表平均O(1)复杂度的前提条件,强调冲突处理的必要性,比较了拉链法和开放寻址法的优劣。重点阐述了装载因子与扩容机制的关系,并给出简化版拉链法实现伪代码。最后指出常见误区,提醒读者注意冲突退化、key一致性等问题。全文强调哈希表的性能优势来自计算定位,但其持续高效取决于合理的冲突控制和扩容策略。
2026-04-23 07:15:00
529
原创 Git 工作区、暂存区、版本库:一次 commit 背后发生了什么
本文简明解析了Git的核心概念——工作区、暂存区和版本库三个区域的关系。工作区是当前编辑的文件,暂存区是准备提交的快照清单,版本库则是已提交的历史记录。通过git add将工作区改动存入暂存区,再用git commit将暂存区内容固化为版本库中的提交。文章还解答了常见问题,如修改未提交、撤销add操作等,强调理解这三个区域是掌握Git命令的基础。暂存区作为"提交前的确认台",在实际开发中非常实用,能帮助开发者更精准地控制提交内容。
2026-04-22 07:30:00
599
原创 什么是 RESTful API?从请求到响应的最小入门实战
本文介绍了RESTful API设计的基本原则和实践方法。首先解释了API和RESTful的概念区别,强调RESTful是一种规范化的接口设计风格。核心内容包括:资源命名应采用名词而非动词,通过HTTP方法区分操作类型;详细说明GET、POST、PUT/PATCH、DELETE的使用场景;建议合理使用HTTP状态码配合业务码;推荐统一的响应数据结构。文章还提供了一个用户资源API的完整设计示例,并指出了常见的设计误区,如动作写进URL、状态码滥用200等。最后总结出RESTful设计的三个关键点:URL描述
2026-04-21 07:30:00
1128
原创 GitHub 上的 CI/CD 怎么用?从 GitHub Actions 到一条可上线的流水线
本文介绍了GitHub Actions作为CI/CD工具的核心概念和使用方法。主要内容包括:1)Workflow、Job、Step等基本概念;2)最小可运行的CI测试示例;3)三种常见的CD触发方式;4)密钥管理的正确做法;5)矩阵构建测试多版本;6)缓存优化技巧;7)常见问题及解决方案。文章提供了前后端通用的流水线骨架,强调权限最小化、环境隔离等最佳实践,并给出了学习CI/CD的自测清单。通过YAML示例和实用建议,帮助开发者快速上手GitHub Actions实现自动化构建和部署。
2026-04-20 07:30:00
646
原创 一文搞懂前端请求重试:从拍脑袋 setTimeout 到指数退避 + 抖动
文章摘要 本文探讨了接口请求重试策略的优化方法。作者指出常见的无脑重试(如线性重试)容易引发同步风暴,导致流量放大。建议采用指数退避算法,让重试间隔随失败次数增长,并加入随机抖动分散请求峰值。文章还强调了重试边界条件:4xx错误不应重试,需尊重429状态码的Retry-After头部。最后提供了工程实践清单,提醒注意幂等性、日志记录等问题。核心观点是:重试应以不恶化系统为前提,通过可控策略提高成功率而非盲目重试。全文包含代码示例和对比表格,极具实操价值。
2026-04-19 10:00:00
487
原创 遗传算法做量化策略优化:把参数调成可控的“进化引擎”
本文介绍了遗传算法(GA)在策略搜索项目中的工程化应用方法。文章将参数分为三个层级:搜索规模(控制实验成本)、搜索风格(决定优化方向)和搜索复杂度(防止过拟合)。详细解析了每个参数的具体作用,如种群大小、进化代数、精英保留数量等,并提供了可直接使用的起步配置。特别强调了复杂度控制的重要性,通过软硬条件限制防止策略过拟合。最后给出了四条实用调参口诀,帮助优化实验效率。文章主张将GA视为可控的搜索工具,而非黑箱优化器,从而实现可追踪、可复盘的策略研发流程。
2026-04-18 07:30:00
796
原创 一文搞懂前端请求超时与取消:从 Promise.race 到 AbortController
本文介绍了两种处理请求超时和取消的方法:Promise.race和AbortController。Promise.race只能实现超时提示,无法真正取消请求,而AbortController可以同时解决超时和用户主动取消的问题。文章提供了最小可用示例和封装方法,并对比了axios的用法。最后总结了常见踩坑点,强调要区分AbortError和HttpError。核心结论是:要真正取消请求就使用AbortController,Promise.race只是计时器功能。
2026-04-17 09:09:38
482
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人
RSS订阅