从「锁」到「时间」：后端里几个容易混的概念

🥰个人主页：会编程的土豆（欢迎来访）

💎作者简介：后端学习者

✨那些你一个人走过的夜路，终将化作照亮未 来的光

学后端一段时间后会发现：很多坑不在语法，而在概念没分清。下面把几件特别容易搅在一起的事拆开说------不绑具体项目，换成别的业务也一样适用。

很多人一听「锁座位 / 锁库存」，以为就是数据库的锁。其实通常有两层：

业务锁

用业务字段表达「这个资源暂时被占用了」。例如：状态改成「已锁定」、记下是谁锁的、记下锁到什么时候。别人查询时看到「已锁定」，就不能再下单。这是业务规则。

数据库行锁（如 SELECT ... FOR UPDATE）

在事务里锁住某一行，防止两个请求同时读到「还空着」然后都更新成功。这是并发控制。

一句话：业务锁回答「能不能卖」；行锁回答「会不会两个人同时改成功」。

下单流程里常见组合是：事务里先加行锁检查状态 → 再改成业务锁定并写入过期时间。

很多系统会说「锁定 15 分钟」「订单 15 分钟未支付自动取消」。实现上通常是：

也就是说：「15」出现在创建资源的时候；释放函数往往不再接收这个 15，只查库里的截止时间是否已过。

可以记成：配置分钟数 → 下单写成绝对时间 → 定时器用「现在 vs 截止时间」清理。

另外，支付超时和锁定超时可以是两条线：一个管订单状态，一个管资源占用；默认分钟数相同，不代表是同一个字段。

Go 的 time.Parse / ParseInLocation 第一个参数不是「举个例子」，而是一套固定占位符，来自参考时间：

2006-01-02 15:04:05

含义对应关系：年用 2006，月用 01，日用 02，时用 15，分用 04。

所以：布局写成 "2006-01-02 15:04" 表示格式是「年-月-日时:分」；用户输入仍然可以是 "2026-08-30 14:00"，年份照样是 2026。

如果你在布局里写 2026，Go 不认它是「年份占位符」，解析就会失败。填什么年份是业务数据；布局里的 2006 是语言规定。

不能。函数内部的变量是局部的，出不了这个函数，更不能被另一个包直接访问。

正确做法是：当参数传过去。

A 包算出截止时间 → 传给 B 包的函数参数 → B 包用自己的参数名接收并写入数据库。

这不是限制，而是封装：谁创建、谁使用，边界清晰。

例如 Go 里写 PayDeadline，库里是 pay_deadline，JSON 也可能是 pay_deadline。

这在 ORM（如 GORM）里很常见：代码用导出字段（大驼峰），表用下划线列名，框架负责映射。

写原生 SQL 条件时要用列名；给结构体赋值时用字段名。记住「同一个东西，两套名字」就不会懵。

Web 应用展示图片，靠的是浏览器能请求到的 URL，例如 /static/img/cover.jpg，而不是 C:\Users\xxx\Desktop\photo.jpg。

原因很直接：浏览器不能随便读用户磁盘；服务端通常只对外提供指定静态目录。

正确流程是：文件放进项目的静态资源目录 → 存相对站点的 URL → 页面用 img 加载。后台如果只是一个「图片 URL」输入框，往往不会自动解析、预览本地文件，只是把字符串存起来。

数据库外键不只是「关联一下」，还决定删主表时怎么办：

所以「删除电影 / 删除商品失败」，不一定是业务代码写了限制，很可能是库里还有订单、场次、明细在引用它。排查时：先看建表 SQL 里的 FOREIGN KEY，再看业务删除逻辑。

后端难的部分，经常不是 CRUD，而是：并发下资源不能超卖、超时状态怎么收敛、配置 / 写入 / 定时清理如何串成闭环。

把概念拆开（业务锁 / 行锁，截止时间 / 定时任务，布局占位符 / 真实年份），代码读起来会顺很多，也更容易向别人讲清楚。

如果你也在学后端，不妨拿自己的项目对照这几条走一遍：哪里加锁、哪里写截止时间、谁负责过期清理。能讲顺，往往比多写一个接口更有用