qq_32276275-优快云博客

原创一个接口从能用到稳定，中间差的到底是什么

一个接口从“能用”到“稳定”，中间并不是多写几个try/catch输入有明确边界，额外字段不会静默生效；上游有超时，超时会真正取消请求；重试有预算，只处理可恢复错误；幂等键绑定参数指纹，进行中的请求也能被复用；错误有稳定的代码、状态码和request_id；测试验证调用次数、重试次数和不会发生的副作用。模型可以换，摘要规则可以换，甚至接口背后的供应商也可以换，但这些边界最好留在自己的服务里。

2026-09-01 17:15:49 265 1

原创 AI 流式输出怎么做才不丢字：SSE、断线重连和重复响应处理

至少记录会话 ID 的哈希、尝试次数、最后发送 ID、最后确认 ID、重连原因、总耗时和结束原因。不要把完整 Prompt 和模型原文直接写进普通日志。AI 流式输出真正难的不是把字符串写到响应里，而是把一次不可靠的网络连接变成一条可恢复的事件日志每段内容有稳定 ID；客户端记录最后处理位置；服务端能按位置重放；客户端在追加前去重；只有明确的done才代表成功结束；重试有上限，错误可观测。这几个边界补齐之后，模型供应商可以换，网络可以抖，代理可以重启，页面仍然不会平白多出一段文字。

2026-08-28 14:58:36 933 1

原创别再凭感觉调 RAG：我做了一个可复现的检索评测台

RAG 调优最怕一句“感觉好多了”。正确文档有没有进 Top K；它排在第几位；最终答案有没有引用它；知识库没有答案时，系统能不能停下来。这篇示例没有假装一个小语料能代表生产效果，反而把评测口径、失败路径和可复现命令全部摊开。你可以先跑基线，再替换自己的 Embedding、分块器和重排器；每次只改一个变量，最后用留下证据。RAG 是否变好，不应该靠演示截图决定，而应该由一组固定问题和一串可比较的数字决定。

2026-08-27 10:12:36 412 1

原创 LLM 返回 JSON 不是加一句“请输出 JSON”：我做了一个可重试、可校验的结构化输出管线

结构化输出的关键不是给提示词加一句“请输出 JSON”，而是把模型当作一个不稳定但有能力的外部依赖先用 Schema 定义协议；再解析模型原始文本；用路径化错误做校验；只进行有限重试；最后才把结果交给业务代码。这样做的价值不在于让模型永远不犯错，而在于模型犯错时，系统知道错在哪里、还能不能重试、是否应该降级，以及怎样留下足够证据。代码很短，边界却比提示词可靠得多。

2026-08-25 15:13:40 485 1

原创我给 10 万篇 Markdown 建了索引：唯一编号快 13 倍，高频词却只快 9%

的1表示从正文列生成摘要；标题权重设为8.0，正文权重设为1.0，标题命中优先；SQLite 的原始bm25()值越小越相关，为了让输出分数更直观，这里取负数并降序排列；LIMIT不只是减少网络返回，它还能避免对海量结果做无意义输出。这次实现最重要的收获，不是“SQLite 很快”，而是搜索性能不能脱离命中率讨论。唯一标识只命中一篇，倒排索引能减少 13 倍耗时；高频词命中 5000 篇，排序和摘要吃掉了大部分优势。

2026-08-24 15:41:31 717 1

原创别只会写提示词：手把手从 0 到 1 实现一个可运行的 AI Agent Skill

从 0 到 1 实现 Skill，真正难的不是写出一段漂亮的提示词，而是把任务拆成清晰契约、可执行步骤、确定性脚本、可验证样例和安全边界。一旦这五件事齐全，Skill 就从“模型可能会做”变成“团队可以复用、自动化可以调用、失败可以定位”的工程能力。你可以先把本文示例跑起来，再替换规则和脚本，做出属于自己的 API 评审 Skill、SQL 安全 Skill 或发布检查 Skill。最小版本不需要完美，但必须能运行、能失败、能解释。

2026-08-21 09:50:36 851 1

原创上传大文件总失败？从零实现可续传、秒传、校验和并发控制的分片上传系统

初始化会话，上传可重试的分片，查询事实状态，验证后原子完成。先用本文的本地文件方案跑通闭环，再把分片存储替换为对象存储，迁移成本会非常低。如果你的团队正在做视频、安装包、数据集或设计稿上传，这套协议可以直接作为接口评审的起点：先把状态和失败路径写清楚，性能优化反而会变得简单。

2026-08-20 14:34:11 571

原创 Promise.all 为什么会把 Node.js 服务打崩？从受控并发、背压到任务取消的完整实战

本身没有错。错的是把它当成了调度系统，把“我能创建多少 Promise”误认为“系统能同时处理多少任务”。真正可靠的异步系统，至少要回答六个问题：入口如何背压？执行槽位多少？任务如何取消？哪些错误允许重试？状态如何持久化？服务关闭时如何收敛？当这些问题都有明确答案时，Node.js 的异步模型才会从“看起来很快”变成“在压力下仍然可预测”。本文示例基于 Node.js 18+，代码中的上游服务地址、认证信息和业务数据均使用占位符。

2026-08-19 14:24:16 759

原创把文生图 API 真正接进产品：从一次请求到可追踪、可重试、可落盘的工程化实践

文生图接口的第一个 Demo 往往只有十几行：把 prompt 发出去，再把返回图片显示出来。可一旦它进入真实产品，问题马上变了：密钥放在哪里？Base64 到底是图片还是文本？用户连续点击怎么办？上游超时后是该重试，还是应该立即报错？这篇文章以为例，把一次“能跑”的调用拆成一条可以上线的链路。接口使用鉴权，请求体包含promptmodelnsize，成功响应的图片位于。

2026-08-18 16:49:29 281 1

原创钱已经扣了，页面为什么还在转圈？一次“支付成功但订单未更新”的完整排查

浏览器跳转结果不作为支付成功凭证；回调先验签并可靠持久化，再快速返回成功；所有回调和消息消费默认会重复、会延迟、会乱序；用唯一约束和条件更新实现真正的幂等；回调负责通知，主动查单和对账负责兜底；前端超时只代表“尚未确认”，不代表“支付失败”。支付系统的可靠性，不来自一条永不失败的链路。它来自链路每断一次，系统都知道如何重试；事件每重复一次，业务都不会多执行；状态短暂不一致时，最终仍能回到同一个事实。所以下次再看到“钱扣了，页面还在转圈”，别急着让用户刷新，也别先重启服务。

2026-08-17 17:34:45 474

原创 Cloudflare + Render 都免费，我的网站为什么还是会“坏”？一次真实部署复盘

免费部署最大的价值，是用很低的现金成本换来一次真实上线；最大的误区，是把它当成没有代价的生产环境。这次经历让我真正理解了一件事：架构不是把 Cloudflare、Render、Node 和 Sharp 连在一起就结束了。你还要知道请求在哪一层等待、资源在哪一层耗尽、失败时谁负责给用户解释，以及当某一层沉睡时，剩下的系统会发生什么。资料核对日期：2026 年 8 月 14 日。

2026-08-14 14:08:58 925

原创同样是 2000×2000 的 PNG，为什么一张 20KB，另一张 13MB？我把像素拆开看了看

前几天整理网页素材时，我碰到两张尺寸完全相同的 PNG。它们都是 2000×2000，都是 RGBA，分辨率和通道数一个不少。第一张只有 20KB 左右，第二张却超过了 13MB。更离谱的是，我只给一张纯色图加入肉眼几乎看不出的轻微噪声，文件就从约 20KB 涨到了 2.5MB。这次不是“PNG 压缩等级没调好”，也不是图片里偷偷藏了十几 MB 的 EXIF。为了把问题说清楚，我做了五张尺寸完全一致的图片，逐步破坏像素之间的规律，再观察 PNG 编码后的体积变化。

2026-08-13 14:38:26 759

原创你发出去的可能不只是一张照片：我用 40 行 JavaScript 读出了拍摄位置

EXIF 最初是为了让照片更好管理，并不是为了追踪用户。但一个有用的设计，在离开原来的使用场景后，也可能变成不必要的信息暴露。对开发者来说，真正值得做的不是把所有字段都列出来炫技，而是让处理默认发生在本地、只读必要字段、不给坐标偷偷发请求，并在导出后做一次反向验证。。链接仅用于说明实验环境，照片元数据解析与清理逻辑均在本文给出。下一次发送“原图”之前，除了看看画面里拍到了什么，也可以多问一句：这个文件还记得什么？

2026-08-12 15:43:47 737

原创同一张照片反复保存 10 次，会烂成什么样？我用 Canvas 做了个“数字复印机”

你大概遇到过这种图：文字边缘像长了毛，人物脸上糊成一片，天空里还有一圈一圈的色块。它明明也是一张 JPG，体积甚至不算小，画质却像从十年前的手机里翻出来的。很多人会说，这是因为图片被“压缩过”。这句话只说对了一半。真正伤画质的，往往不是某一次压缩，而是图片在聊天软件、编辑器和内容平台之间来回流转时，被了一遍又一遍。就像拿一张复印件继续复印。第一张还能看，第十张已经不是原来那回事了。我用浏览器 Canvas 写了一个小实验，想看看同一张照片连续保存 10 次以后，像素究竟经历了什么。

2026-08-11 16:29:00 485

原创 2MB 图片也能拖垮免费 Node 服务？我给在线图片站加了 5 层防护

限制上传体积和 Multipart 复杂度；解码前检查真实格式、尺寸、页数和总像素；使用令牌桶限制持续请求；使用并发闸门控制瞬时 CPU 与内存峰值；为编码、请求和连接设置超时；顺序评估候选并及时释放落选 Buffer；把适合本地处理的功能留在浏览器。真正可靠的防护不是某一个限流中间件，而是让每一层都回答一个具体问题：这个文件能不能接、这个请求该不该进、现在有没有资源处理、任务最晚什么时候结束。

2026-08-07 15:23:13 407 2

原创我给网站加了个“不上传服务器”的图片转换器：20 张 PNG/JPG/WebP 在浏览器里直接互转

这次功能看起来只是“三种格式互转”，真正需要处理的却是浏览器编码能力、透明通道、并发峰值、异步竞态和资源释放。对小型在线工具来说，把适合本地完成的计算留在用户浏览器里，是一条很实用的路线：隐私更直接，响应更快，服务端成本也更可控。技术选型不一定要追求最复杂。能够稳定完成、边界清楚、用户拿到真实可用的文件，比堆更多格式名称重要。

2026-08-06 10:44:06 783 1

原创 PNG、JPEG、WebP、AVIF 到底怎么选？格式选错，压缩参数调半天也没用

照片优先比较 JPEG、WebP 和 AVIF；透明和无损需求优先考虑 PNG；网页通用输出优先考虑 WebP；AVIF 适合有编码预算和回退能力的场景；代码截图、二维码和细线图形不要盲目使用有损压缩；不要跨格式比较相同的质量数字；不要根据扩展名判断真实格式；Canvas 导出后必须检查 Blob MIME；默认保留原格式，跨格式优化交给明确的智能模式。PNG、JPEG、WebP 和 AVIF 不是四个从旧到新的版本，也不是简单的“谁体积小谁最好”。它们解决的是不同问题。

2026-08-05 09:37:11 592

原创上传 20 张图片后页面越来越卡：文件没多大，浏览器却可能吃掉 1.8GB

图片处理页面越用越卡，未必是 React 渲染太多，也未必是某个库性能差。很多时候，真正的问题是我们创建了图片资源，却没有为它设计完整的退出路径。Object URL 要回收，要关闭，Canvas 要缩短生命周期，批量任务要限制并发，过期结果也要销毁。优化图片工具的关键，不是让每个任务跑得更猛，而是控制同一时刻有多少资源活着，并确保它们在正确的时间离场。以上实践来自我开发 Pixel Slim 图片工具时对批量压缩、尺寸调整和拼图流程的整理。

2026-08-04 14:07:03 294

原创 React 切换 Tab 一闪一闪的，我最后发现问题根本不在 CSS

动态import()会复用同一个模块请求，不需要自己维护一套复杂缓存。这次排查让我重新认识了一个问题：页面“闪一下”往往不是某一条 CSS 写错了，而是用户看到的组件已经被销毁并重新创建。最终方案可以概括为四句话：首次按需挂载，后续保留状态；用户表达意图时预加载；空闲时补齐分包；切换路由和语言时只更新必要状态。体验优化有时不是再加一个动画，而是让本来不该消失的东西，别消失。

2026-08-03 15:06:04 401

原创我给长图拼接加了一个功能：自动识别重复截图区域

长图拼接表面上是把图片从上往下画，真正影响体验的却是重复区域检测和失败兜底。缩小截图用于分析↓比较前图底部与后图顶部↓保存最佳重叠比例和置信度↓按原图尺寸裁剪并导出它不依赖 OCR，不需要 AI 模型，也不需要把聊天截图上传到服务器。我把这套能力应用到了 Pixel Slim 的长图拼接功能中。上传多张连续截图后，工具会自动估算相邻图片的重叠区域，也允许逐张手动调整裁剪比例。模板拼图、自由拼图和长图拼接都在当前浏览器内完成。

2026-08-03 09:04:08 457

原创我以为 Canvas 拼图只是 drawImage，最后却写了半个图片编辑器

从一个简单的模板布局和自由布局；画框变换和图片内容变换；contain与cover；鼠标坐标和图层局部坐标；拖动、缩放、旋转和锁定；图层顺序和吸附参考线；专注模式和页面滚动恢复；透明背景和输出格式联动；预览与高清导出一致性；撤销、重做和历史快照。这些功能单独看都不复杂，但只要有一个坐标或状态没有分清，用户就会感到“不跟手”“被裁掉”或者“下载结果不一样”。

2026-07-31 14:50:45 267

原创半透明水印为什么总有残影？从邻域填充到反向 Alpha 还原

从“涂抹覆盖”到“反向 Alpha 还原”，最大的变化不是代码变复杂了，而是重新理解了问题：半透明水印不是一块需要填掉的污渍，而是一组仍然包含原图信息的混合像素。水印颜色识别；逐像素透明度估计；抗锯齿边缘；蒙版边界扩张；多层水印和阴影；普通背景误涂保护；半透明与不透明遮挡的算法分流。我把这套实现应用到了 Pixel Slim 的本地图片修复功能中。用户可以涂抹候选区域，选择透明水印还原或不透明内容修补，处理过程在当前浏览器内完成。

2026-07-31 10:30:00 212

原创一张 10MB 的照片，为什么能吃掉浏览器近 100MB 内存？

前端图片处理最危险的误区，是把“文件体积”当成“内存占用”。一张 10MB 的照片，解码后可能接近 100MB；同时处理十张，就可能把一个普通网页变成内存压力测试。解码后的真实内存；并发任务数量；预览与导出分辨率；Blob、Object URL 和 Canvas 的生命周期；移动设备的性能边界；单张图片失败后的任务隔离。我把这些实践应用到了 Pixel Slim，目前支持批量压缩、尺寸修改、拖动裁剪、自由拼图、长图拼接、透明背景和局部图片修复。

2026-07-30 14:29:04 594

原创 Canvas 裁剪预览正常，下载却错位？问题通常出在这 3 套坐标

在线图片裁剪看起来只是调用一次原图、预览和导出坐标换算；contain与cover的选择；画框与图片内容状态分离；CSS 尺寸与 Canvas 内部尺寸转换；高清导出和透明背景处理。这些问题也是我在开发 Pixel Slim 时持续优化的部分。图片批量压缩；修改图片宽高；实时预览和拖动裁剪；自由拼图和长图拼接；透明背景；局部图片修复；中英文界面。如果你的 Canvas 编辑器也出现“预览正确、导出错位”，先别急着修改。

2026-07-30 09:44:55 1150

原创我用 React + Canvas 做了一个在线图片工具，最先崩的不是服务器，而是浏览器

最初，我只是想做一个简单的图片压缩页面。用户上传图片，Canvas 重新绘制，再调用 toBlob() 导出。几十行代码就能跑起来，看起来没什么难度。直到我一次性拖入多张手机照片。页面开始卡顿，内存持续上涨，预览出现空白，最后整个标签页直接失去响应。我这才发现：浏览器能处理图片，不代表它能随便处理图片。

2026-07-29 10:55:24 606

原创做图片处理，真的没必要装一堆软件

以前遇到这些问题，我通常要打开好几个网站，甚至临时安装软件。于是我做了一个免费的在线图片工具：Pixel。最重要的是，常用编辑直接在浏览器里就能完成。上传、调整、预览、下载都集中在一个页面，不用在多个工具之。图片太大传不上去、尺寸不合适、截图要拼成长图、画面里还有不想要的内容……一个小工具未必能替代专业软件，但它可以让日常图片处理少几步、快一点。

2026-07-29 09:23:53 634

原创我把一个图片压缩 Demo，做成了真正能用的在线工具站

一开始，我只是想写一个图片压缩页面。上传图片，调用 Sharp，设置质量参数，返回压缩结果。代码并不复杂，半天就能做出一个能跑的 Demo。但当我真的开始使用它，问题很快出现了：压缩后的图片为什么不够小？固定质量是否适合所有图片？PNG、JPEG、WebP 应该怎么选？批量处理失败一张，其他任务要不要继续？用户不选择输出格式时，应该转换格式还是保留原格式？我逐渐意识到：能处理图片和做一个好用的图片工具，是两件完全不同的事。

2026-07-28 15:39:03 488

原创为了少开几个网站，我做了一个免费的在线图片工具箱

作为开发者，你大概率遇到过这种场景：项目准备上线，图片太大要压缩；运营临时要一张固定尺寸的封面；写文章需要拼接截图；好不容易处理完，却发现图片变糊、被裁掉，或者还要注册登录才能下载。为了处理几张图片，我经常要在多个网站之间来回切换。于是我决定自己做一个：Pixel Slim。最初它只是一个批量图片压缩工具，后来根据实际使用中遇到的问题，逐步加入了尺寸修改、可视化裁剪、模板拼图、自由拼图、长截图拼接和水印处理。

2026-07-27 17:42:29 466

原创为了达成目标，我给自己写了个专注小程序，名叫“筑屿”

一款简约，方便的专注小程序。筑屿是一款不制造焦虑的专注小程序。你可以拆分任务、沉浸计时、设定每日目标，并通过记录、勋章和周。每一次投入，都不会因偶尔停下而被清零。

2026-07-23 09:27:06 73

原创不想再装图片软件了，我做了一个浏览器里的图片工具箱

✅ 批量图片压缩一次最多处理 20 张图片，支持 JPEG、PNG、WebP、AVIF。平时想压缩几张图片、修改尺寸或者拼个长图，经常需要打开不同网站。✅ 图片拼接提供网格、横向、纵向、主图布局等模板，也支持自由拖动、缩放、旋转和调整层级。单张图片可以直接预览，自由拖动构图、放大缩小，再裁剪成需要的尺寸。✅ 图片去水印支持处理半透明文字水印，也可以涂抹修补不透明区域。✅ 中英文切换手机和电脑都可以直接使用，不需要安装软件，也不需要注册账号。

2026-07-22 15:27:43 570

qq_32276275的博客