有状态的东西别硬塞进函数，放到外头存才稳当些

我爱LV游 · 发表于 2026-11-07 10:11:08

函数跑完环境就可能收走，写在本地的那点东西下一回未必还在。把会话、进度、临时文件都当成长久存在的，头几次试都正常，等实例一换，问题才冒出来，还特别难复现。

一、本地文件靠不住

中间产物别落在函数自己的盘上，落了就默认它随时会没。要留的往共用的存储里写，写的时候按编号起名字，别让两笔请求抢同一个文件名。审批时问一句这个写动作会不会被重试送到两次，问过之后再上线，比出了两份流水再补认重便宜，补的时候还得回头清理已经发出去的那批。

确实要临时用一下的，也得在函数结束前清掉。不清的话，同一份环境被下一笔复用，读到的是上一笔剩下的半截内容，错得毫无规律。预算里把共用存储那份单列出来，搬状态出去看着只是换个地方放，连接数、请求次数都在计费，摊开算过才不会在月底觉得多出一笔说不清的开销。

二、连接要复用

每笔请求都新建一次数据库连接，握手的时间比干活还长。在函数外面留一份可复用的连接，环境与在就接着用，收走时再按规矩关掉。收尾窗口定过之后记在值班手册里，注明是哪次讨论定的、当时参照了哪类活，往后业务形状变了要重定时，翻得到原来的依据，改起来也有个对照。

复用的连接要设个空闲上限，一直挂着也会把库那边的连接位占满。占满了新请求进不来，报出来的错还指着业务代码，容易往错方向查。交接单上写明哪些会话还挂在公共缓存、过期时间定的是多少，接手的人碰到有人反复被要求重登，能先往这处想，而不是先怀疑登录逻辑。

三、会话放外头

用户登录后的状态存到公共的缓存里，函数本身只认一个钥匙。这样请求落到哪个实例都一样，不会出现在甲上还登着、换到乙上就得重来一遍。两边碰同一条数据怎么处理，写进共同的约定并各留一份，新人进来先读这一页，比靠老同事口头带一遍稳，换人之后做法也不至于悄悄分叉。

钥匙的过期时间写清楚，别设成永不失效。永不失效的那批状态越攒越多，清理时又分不清哪些还活着，只好整批留着，成了一笔糊涂账。交接时把前一班留意到的几处偏高的数值抄给下一班，附上当时有没有人在改东西，接手的人有了这层背景，判断起来就有了起点，不必从零试。

四、幂等先做

同一笔请求可能因为重试被送到两次，写动作要能认出重复。认不出来就多发一条通知、多记一笔流水，用户看到的是两份，对账时还得人工挑出来。发版窗口之后留一段盯盘时间写进值班表，发布快不等于可以立刻散，那十几分钟里失败率的短时对比很能说明新版站没站住。

认重用的键按业务本身定，别拿时间戳凑合。时间撞在同一秒是常事，凑合出来的键看着不重复，真并发起来根本挡不住。复盘会把重复发出去的通知挑出来数一数，根子多半在认重的键没按业务定，拿时间戳凑合，并发一上来挡不住，事后又得人工挑一遍。

五、并发写要控

瞬间扩出一大批实例，一起往同一处写，库那边先扛不住。写之前按业务键排一下，或者用带版本的更新，让后来那笔知道自己踩到了别人改过的数。

冲突时的处理写在明处：是退回让上游重试，还是按规则合并。没写就各凭实现，有的静默覆盖、有的直接报错，同一类问题冒出好几种表现。新人上手先让他做一次并发写的练习，看着两笔同时改同一条会出什么，再讲带版本的更新为什么必要，比先背规则印象深。

六、回收前留信号

环境要被收走之前留一条信号，让还没跑完的活有机会收尾。没有这个信号，恰好卡在写一半的那笔就被截断，留下一份谁也不完整的记录。

信号给的时间别太短，短了等于没有；也别太长，长了实例迟迟退不掉，空闲开销又回来。按这批活正常收尾所需的时间量一量再定。归档把幂等键的选取依据写进接口说明，过半年换人维护，看到那个键不至于觉得多余而顺手改掉，改掉之后重复请求就又挡不住了。

函数适合拿来算，不适合拿来记。文件、连接、会话、幂等、并发、回收，六处都按「随时会走」来设计，跑得再短也稳；哪一处当成常驻，就等着某次实例轮换给你上一课。

zxc888 · 发表于 2026-11-07 10:11:09

这样的优质帖子越多越好，希望论坛能多一些这样真诚的交流。

额。小P孩！ · 发表于 2026-11-07 10:20:55

楼主的经历很有参考价值，给了我很多新的思考方向，非常感谢。

leonseo2 · 发表于 2026-11-07 10:22:26

内容真实不做作，没有多余套路，都是实实在在的经验之谈。

		自动登录	找回密码
密码			加入W10