FWDD.NET · 技术文档站

范文多多

聚焦后端工程实践：语言教程、功能实现、面试题与运维脚本。每篇都从真实踩坑场景出发，给出可直接复用的代码与取舍依据。

磁盘清理脚本：日志轮转加阈值告警

服务器磁盘被打满的原因，九成是日志没人管。写一个能定时跑、超阈值会叫人的脚本，比事后救火体面得多。需求拆解按时间清理 N 天前的日志磁盘使用率超过阈值时告警找到并处理异常大的单个文件全程记日志，方便事后追溯脚本 #!/bin/b

标准答案是"防止历史重复连接初始化"。但这题真正的分量在于你能不能用序列号把整个过程讲清楚。核心：确认双方的双向收发能力三次握手交换的是 ISN（Initial Sequence Number，初始序列号）：客户端服务端 |----

这题考察的是对存储介质的理解，而不只是背结论。要点在于：数据库的数据最终要落盘，而磁盘随机 IO 比内存慢 5 个数量级。先看三个候选的问题哈希索引：等值查询 O(1)，很快。但不支持范围查询（WHERE age > 20 没法

这题几乎是 Go 面试的开场题，但很多人只答出"一个初始化一个不初始化"，没说到点子上。核心差异在于返回的类型和适用场景。标准答案 | | new(T) | make(T, ...) | |---|---|---| | 返回类型 | *T

排行榜、Top N、分组取最新一条——这类需求用窗口函数写起来最舒服。但老代码里常见的是自连接或子查询写法，数据量一上来就慢到不可用。一个典型场景每门课程要取分数最高的前 3 名学生。自连接写法： SELECT s.* FROM sco

调用第三方接口，网络抖一下很正常。但"失败就重试"如果写得随意，反而会把对方打挂、把自己的线程占满。一个可靠的重试客户端要同时满足：会退让、有边界、可取消。最容易踩的坑 for i := 0; i < 3; i++ { resp,

限流是后端最常用的自我保护手段。固定窗口实现简单但有临界突刺，滑动窗口更平滑但开销大。折中方案是令牌桶：既允许合理突发，又能扛住持续高压。为什么不用固定窗口固定窗口（每秒计数）的问题在边界：第 0.9 秒来 100 个请求，第 1.1

Go 1.18 引入泛型后，最实用的场景之一就是把"返回值 + 错误码"这种固定结构的接口统一起来。本文用一个小例子讲清楚约束怎么写、什么时候该用。问题：重复的返回结构每个业务接口都要返回"数据 + 状态码 + 消息"，手写三遍很烦：

asyncio 里"超时"和"取消"是一件事的两面：超时本质上是到点发取消信号。但很多代码只包了 wait_for 就以为万事大吉，真正的问题往往出在被取消的任务不肯干净退出。最基础的写法 async def fetch(session,