最稳妥的克隆方式是显式列出字段名，避免用 select *；需手动处理主键、默认值、时间戳及唯一约束，并通过后端接口获取原始数据再修改，确保字段语义和约束对齐。
mysql 中用 insert ... select 快速克隆单行记录
直接复制某一行数据并插入新记录，最稳妥的方式是显式写出字段名，避免隐式依赖表结构顺序。很多人图省事用 insert into t select * from t where id = 123，但一旦表加了字段、调了顺序或有计算列，就会报错或插错值。
- 必须明确列出目标字段和源字段，两边一一对应，例如：
INSERT INTO user (name, email, status) SELECT name, email, 'draft' FROM user WHERE id = 456 - 如果要忽略主键（如
id）自增，就别把它写进字段列表，也别在SELECT里选它；否则可能触发重复主键错误 - 注意
DEFAULT值不会自动生效——SELECT不会读取列默认值，得手动写，比如SELECT ..., 'pending' AS status - 时间戳字段（如
created_at）若设了DEFAULT CURRENT_TIMESTAMP，显式插入NULL或不包含它，才能触发默认行为
PostgreSQL 里用 INSERT ... DEFAULT VALUES + RETURNING 配合更新
PG 不支持 MySQL 那种无字段列表的 INSERT ... SELECT * 直接克隆，但可以用 RETURNING 拿到原记录再插——更安全，也方便后续改字段值。
- 典型写法：
INSERT INTO orders (user_id, total, status) SELECT user_id, total, 'cloned' FROM orders WHERE id = 789 RETURNING id - 如果只想改一两个字段，其他全照搬，就只在
SELECT里替换那几个，其余仍用原字段名 - 别漏掉
RETURNING后面的字段——它不返回新记录全量，只返回你写的那些，比如只写RETURNING id就拿不到新生成的created_at - PG 对 NULL 和空字符串敏感，
SELECT出来的NULL会原样插入，不会被默认值覆盖，这点和 MySQL 行为不同
前端表格里点击“克隆”按钮时，后端该怎样防错
用户点一下就复制一行，背后最容易出问题的是并发写入和字段校验脱节。不是所有字段都能直接复制，比如唯一索引、状态机字段、关联外键都得重置或校验。
- 必做校验：检查目标表是否有唯一约束字段（如
email、code），克隆前要清空或生成新值，否则INSERT直接报duplicate key - 状态字段（如
status）通常不能原样复制，得强制设为初始值，比如从'published'改成'draft' - 外键字段（如
category_id）要确认关联记录是否还存在，否则插入会因外键约束失败，报错insert or update on table "xxx" violates foreign key constraint - 别在前端拼 SQL 字符串传给后端——哪怕只是克隆，也要走参数化查询，防止字段名注入（比如用户篡改请求把
name换成id); DROP TABLE users; --）
为什么不用 JavaScript 在浏览器里直接 clone 一行 DOM 然后发请求
可以 clone DOM 行，但不能只靠它生成可靠数据。表格展示的数据常经过格式化（比如日期转成 “2024-05-20”，后端存的是时间戳）、过滤（隐藏字段没渲染）、或本地计算（如 total = price * qty），直接取 innerText 会丢精度、类型和业务逻辑。
- DOM 里的值是字符串，数字可能被千分位分割（
"1,234.50"），发给后端前不 parse 就会当字符串存，导致数值字段入库失败或截断 - 隐藏列（如
is_archived）或计算列（如discounted_price）根本不在 DOM 里，光 clone 行拿不到这些字段 - 时间类字段显示为本地格式（如 “昨天 14:30”），但后端需要 ISO 时间戳，不转换就发过去，API 通常直接拒收
- 真正省事的做法：点击克隆时，用原记录的 ID 请求一次后端接口（如
GET /api/items/123），拿到原始数据再修改必要字段，最后POST创建
克隆看着简单，实际卡点都在字段语义和约束上——ID 主键、唯一索引、外键、默认值、时间类型、前端展示与存储格式差异，任何一个没对齐，就停在报错那行不动。
