商品管理系统Golang实现核心在于数据建模分层（Req/DB/Domain）、sqlx事务批量操作、游标分页与前缀搜索、软删除+条件唯一索引、OSS直传图片。
商品管理系统在电商后台中核心是“增删改查+状态流转”，Golang 实现的关键不在于框架选型，而在于数据建模是否贴合业务、CRUD 接口是否预留扩展点、以及并发安全是否被默认保障。
定义商品结构体时必须区分「领域模型」和「数据库模型」
直接用 Product 结构体同时承载 HTTP 请求参数、数据库字段和业务逻辑，后期加库存扣减、SKU 拆分或审核状态时会迅速失控。
- 用
ProductCreateReq接收 POST 请求，只含必要字段（如Name、Price、CategoryID），禁用指针字段避免零值误判 - 数据库模型
ProductDB加CreatedAt、UpdatedAt、Status（int8 类型，0=草稿 1=上架 2=下架）等运维字段，且所有字段加db:tag - 领域模型
Product用于 service 层编排，可嵌入*SkuList或CategoryName等聚合字段，不直连数据库
使用 sqlx + NamedExec 处理批量插入与更新
原生 database/sql 对多行 INSERT 支持弱，手写占位符易出错；用 sqlx 的 NamedExec 可读性高，且自动处理 struct 字段映射。
- 插入多 SKU 商品时，先用
tx.NamedExec插入主商品，再用tx.NamedExec批量插入product_sku表，共用一个事务 - 更新商品基本信息时，用
UPDATE product SET name = :name, price = :price WHERE id = :id配合map[string]interface{}，避免拼接 SQL 注入风险 - 禁止在循环里开新连接或事务，
sqlx.DB本身已带连接池，复用即可
GET /products 接口必须支持分页、按状态过滤、模糊搜索
前端管理页不可能一次性拉全量商品，但若后端只做简单 LIMIT OFFSET，数据量大时性能急剧下降。
立即学习“go语言免费学习笔记（深入）”；
- 用游标分页替代 offset：要求前端传
last_id（上一页最后一条的 ID），SQL 改为WHERE id > ? ORDER BY id LIMIT 20 - 状态过滤走
Status字段索引，不要用LIKE '%手机%'全表扫描，搜索关键词走name字段的前缀匹配（name LIKE ?，参数为"手机%"） - 返回结构中显式包含
Total字段，但不要用SELECT COUNT(*)全表统计——改用缓存预估数或异步计数服务，否则列表接口变慢十倍
软删除必须配合唯一约束与业务状态字段
Golang 后台不能依赖 DELETE FROM product，否则订单关联商品后无法回溯，历史数据丢失。
- 数据库字段加
deleted_at DATETIME NULL，用gorm.DeletedAt或自定义IsDeletedbool 字段均可，但必须在所有查询 WHERE 条件中显式过滤deleted_at IS NULL - 商品名需加唯一索引，但允许软删除后重用名称——索引应为
UNIQUE KEY idx_name_not_deleted (name) WHERE deleted_at IS NULL（MySQL 8.0+ 支持） - 上架/下架操作不删数据，只改
Status字段；真正归档走独立的/admin/products/archive接口，且需二次确认 + 操作日志
最易被忽略的是「商品图片 URL 的存储方式」：别把图片二进制存数据库，也别让前端直传到后端再中转——用预签名 URL 直传 OSS，后端只存 oss_path 字符串。否则单次上传卡住整个 HTTP 连接，goroutine 泄露风险极高。
