109 篇博文 含有标签「Node.js」

node.js 加载其他模块时要使用require(路径) ,路过路径加载的一般都是文件模块,程序首先会加上.js扩展名尝试去搜索,如果找不到,就尝试用 .json 格式扩展名去搜索加载,还找不到,就加上扩展名 .node 去搜索加载.

何为核心? 重要的/不可缺的!

问题如上描述:express bodyParser post上传文件request.body 不能获取表单值

web下的提交数据的方法有2种,GET,POST,不明白的可以直接去面壁了.

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-06 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

如果只用一个真实链路来解释这个标题，我会选“内部知识问答 API”。

这套服务最开始的目标很简单：前端把用户问题丢给后端，后端转发给模型，再把答案返回。最早大家以为复杂度会集中在业务逻辑上，比如：

• 检索怎么做
• 答案怎么组织
• 是否需要引用来源

但上线后很快发现，真正最先失控的不是这些，而是业务层外面那一圈：谁能调用、该走哪个模型、超时怎么退、缓存怎么命中、配额怎么算、错误怎么统一。

也就是说，业务逻辑还没来得及长大，网关层已经先膨胀了。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-09 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

AI 功能一旦进入真实流量，成本问题迟早会从“财务关心的事情”变成“工程必须立刻处理的事情”。最麻烦的是，它通常不会一开始就用一种非常明显的方式爆炸，而是会先通过一些不太起眼的信号慢慢浮上来。等到大家真正感觉到痛，往往已经不是“优化一下”能解决的程度了。

我现在看 AI 接口成本是否快要失控，不会先看总账单，而会先看系统里有没有出现下面三个信号。它们一旦出现，就意味着网关层和调度层必须尽快补队列、缓存和限流，不然越往后越被动。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-25 11:40。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

如果只拿一个线上场景来说超时策略，我会选“知识问答 + 检索 + 工具调用”的组合请求。

这类请求最容易暴露一个错觉：团队经常以为“只要给 SDK 设一个 30 秒超时就够了”。但真实请求进来之后你会发现，30 秒这个数字根本没有回答任何关键问题：

• 用户愿意盯着这个页面等多久？
• 整条链路最多能烧掉多少预算时间？
• 单个检索或工具步骤慢到什么程度时就该放弃？

当这些问题没有分开，超时就不会是一个边界，而只是一个会随机爆炸的数字。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-30 10:20。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多人做 AI 服务优化时，一看到延迟上来，第一反应就是“加缓存”。这当然不是错，但问题在于：缓存并不是天然减延迟，它只是在某些命中条件下减延迟。

前阵子我就遇到过一次很典型的反效果。团队本来是想给一条 AI 处理链降一点时延，结果缓存加上去之后，p95 反而更高了。

后来排查下来，问题不是 Redis 慢，也不是代码写挂了，而是我们缓存错了层。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-11-17 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

围绕「一个 API 超时设置救了线上体验」，我希望沉淀出一个能被后续项目复用的判断框架。

短更以单点观察为主，重点记录一个具体问题、一次实验或一个小的工程判断。