★ FEATURED ARTICLE 1. 为什么约束不是“可有可无的装饰”而是MySQL表结构的脊梁骨刚入行那会儿我带过几个实习生他们写CREATE TABLE语句时几乎清一色只写字段名和类型比如id INT,name VARCHAR(50),email VARCHAR(100)然后就直接加个;收工。有一次上线前做数据校验发现某张用户表里居然存了27条email为NULL的记录而业务逻辑里所有邮件通知都默认走这个字段——结果就是整整一天的用户反馈邮件石沉大海。回查SQL才发现建表时压根没给email加NOT NULL更别提UNIQUE了。数据库没拦住应用层又没做兜底校验问题就这么悄无声息地埋进了生产环境。这就是约束最真实、最痛的日常它不显山不露水平时你感觉不到它的存在可一旦缺失它带来的不是报错而是静默的数据腐败——数据看起来“能存进去”但实际已经偏离了业务世界的规则。MySQL里的CONSTRAINT从来就不是教科书里一个冷冰冰的语法概念它是你在设计表结构时亲手给数据世界划下的第一条法律红线。它决定了哪些值允许出现哪些组合绝对禁止哪些变更必须连带更新哪些删除会被当场叫停。没有约束的表就像没有交通信号灯的十字路口车能开过去但没人敢保证会不会撞上。你可能觉得“反正应用层会校验”但现实是校验逻辑分散在N个服务、M个接口、几十个前端页面里漏掉一处数据就裂开一道缝而约束是唯一一处集中、强制、不可绕过的守门人它运行在数据库内核层任何客户端不管是Java、Python、PHP还是某个临时写的Shell脚本只要连上数据库执行INSERT/UPDATE就必须先过它这一关。它不讲情面不看你是谁写的代码也不管你有没有调用SDK——它只认SQL语句本身是否合规。所以当你看到“MySQL创建表时的约束”这个标题别把它当成一个语法复习题。它本质上是在问你准备如何用最少的代码构建出最坚固的数据防线这条防线要能扛住开发者的疏忽、测试用例的遗漏、第三方系统的误操作甚至自己半年后回来看代码时的遗忘。接下来我会带你一层层拆开每种约束的筋骨它到底锁住了什么为什么非得用它而不是靠代码在真实项目里它怎么和索引、外键、事务协同作战以及——那些踩过坑的人都在哪些地方栽了跟头。2. 四大核心约束逐个解剖不只是语法更是设计哲学2.1 NOT NULL最朴素却最容易被轻视的底线NOT NULL看起来最简单但它解决的是数据建模中最根本的问题某个字段在业务语义上是否允许“不存在”不是技术能不能存NULL而是“NULL”这个值在你的业务里有没有明确含义。比如user表中的username如果业务规则要求每个用户必须有用户名那NULL就不是一个合法状态它代表“数据缺失”而非“用户选择不填”。这时候NOT NULL就是强制你面对这个事实要么在INSERT时提供值要么让SQL失败——失败总比存进一个无法解释的空值强。提示NOT NULL会自动为该列创建一个隐式“非空检查”但它不等同于索引。很多人误以为加了NOT NULL就能加速WHERE查询其实不会。如果你需要按该列快速查找仍需单独建索引。实操中一个经典误区是把NOT NULL和默认值DEFAULT混为一谈。比如CREATE TABLE orders ( id INT PRIMARY KEY, status VARCHAR(20) NOT NULL DEFAULT pending );这里status被强制非空但如果INSERT时不指定值MySQL会自动填入pending。但注意DEFAULT只是兜底策略它不改变NOT NULL的语义强度——哪怕你设了DEFAULT 只要业务上空字符串和NULL一样代表“无效”那这个DEFAULT反而掩盖了问题。我见过某电商系统把shipping_address设为NOT NULL DEFAULT 结果导出报表时发现成千上万条订单地址是空字符串而业务方一直以为“有地址”——因为数据库没报错应用也没校验空字符串。真正严谨的做法是先厘清业务语义。如果shipping_address在订单创建时可以为空比如用户选“到店自提”那就该允许NULL并在应用层明确处理NULL场景如果它必须存在则NOT NULL合理DEFAULT如unspecified才是正解。2.2 PRIMARY KEY不只是唯一标识更是聚簇索引的物理锚点PRIMARY KEY常被简化为“主键”但它的双重身份才是关键逻辑上它是表中每一行的唯一身份证物理上它直接决定了数据在磁盘上的存储顺序。在InnoDB引擎下主键不是附加属性而是表结构的骨架。当你定义PRIMARY KEY (id)InnoDB会以id值为序将整行数据包括所有其他列组织成B树的叶子节点——这就是聚簇索引Clustered Index。这意味着按主键查询是最快的因为数据就在索引页里而按其他列查询如果没建索引就得全表扫描。所以选主键绝不是随便挑个id INT AUTO_INCREMENT就完事。我参与过一个日志分析系统原始设计用BIGINT自增ID作主键单表数据量超20亿后插入性能断崖下跌。后来我们重构成PRIMARY KEY (log_date, log_id)其中log_date是分区日期如20240501log_id是当日内自增序号。效果立竿见影写入时新日志天然聚集在最新日期的B树分支减少页分裂查询某天日志时WHERE log_date 20240501能直接定位到对应子树避免全表扫描即使不加额外索引按日期范围查询也极快。注意InnoDB要求每张表必须有且仅有一个聚簇索引。如果你没显式定义PRIMARY KEY它会找第一个NOT NULL且UNIQUE的列都找不到就隐式创建一个6字节的ROW_ID作为主键——这会导致所有二级索引都变大因为二级索引叶子节点存的是主键值用于回表且无法控制数据物理分布。另一个血泪教训主键一旦设定尽量避免修改。曾有个订单系统因早期设计缺陷用order_no字符串作主键后期发现排序慢、索引大。想改成id BIGINT结果发现所有关联表的外键、应用层缓存Key、历史SQL都强依赖order_no。最终花了三个月重构代价远超初期设计成本。所以我的建议是主键优先选窄、稳定、单调递增的整型如BIGINT业务字段如订单号、手机号一律用UNIQUE KEY约束而非主键。2.3 UNIQUE业务规则的硬性声明也是索引的隐形推手UNIQUE约束的核心价值在于它把一句模糊的业务需求“用户名不能重复”翻译成数据库可执行、可验证的机器指令。语法上UNIQUE (username)和UNIQUE KEY uk_username (username)效果相同但后者显式命名约束便于后续管理如DROP INDEX uk_username ON users。更重要的是UNIQUE会自动创建唯一索引——这是它和NOT NULL的本质区别NOT NULL只做检查不加速查询UNIQUE既做检查又提升查询效率。但这里有个极易被忽略的细节UNIQUE索引允许NULL值且允许多个NULL。SQL标准规定NULL表示“未知”两个NULL不相等因此UNIQUE约束下你可以插入多行username NULL。这在某些场景是合理的如用户未设置昵称但在另一些场景却是陷阱。比如某社交平台要求“邮箱或手机号至少填一个”设计为CREATE TABLE users ( id INT PRIMARY KEY, email VARCHAR(100) UNIQUE, phone VARCHAR(20) UNIQUE );本意是防重但用户A填了邮箱用户B填了手机号用户C两个都填了——没问题。可如果用户D两个都不填emailNULL, phoneNULLUNIQUE不拦他结果表里就出现了“无联系方式”的脏数据。正确解法是用CHECK约束MySQL 8.0.16或应用层逻辑确保至少一个非空。实战中UNIQUE常和PRIMARY KEY配合使用。比如用户表CREATE TABLE users ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, email VARCHAR(100) NOT NULL UNIQUE, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );这里id是主键物理组织username和email是业务唯一键逻辑规则。好处是id保证内部高效username/email保证业务正确登录时查WHERE username ?走UNIQUE索引毫秒级响应即使id泄露如URL里暴露/user/123也不会直接暴露业务标识。2.4 FOREIGN KEY跨表关系的契约不是可选的“锦上添花”外键约束FOREIGN KEY常被质疑“影响性能”“增加复杂度”甚至被很多团队明令禁用。但它的本质是在数据库层面固化两张表之间的业务契约。比如订单表orders和用户表usersCREATE TABLE orders ( id BIGINT PRIMARY KEY, user_id BIGINT NOT NULL, amount DECIMAL(10,2), FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE );这行FOREIGN KEY声明了铁律orders.user_id的每一个值必须在users.id中存在。它堵死了“孤儿订单”订单指向一个已被删除的用户的可能性。ON DELETE CASCADE是外键的灵魂选项之一。它意味着当users表中某用户被删除时该用户所有订单自动级联删除。这看似危险实则是对业务场景的精准映射——比如某SaaS系统客户注销时其所有项目、文档、日志必须彻底清除否则残留数据会引发权限和计费混乱。此时CASCADE不是偷懒而是主动承担清理责任。但外键也有代价写入性能损耗每次INSERT/UPDATEordersMySQL都要去users表查user_id是否存在涉及额外I/O死锁风险升高DELETE FROM users WHERE id123会先锁users行再锁orders中所有匹配行若并发高易与订单更新事务冲突迁移难度大跨库、分库分表时外键无法跨实例生效。所以我的经验是在单库单表、强一致性要求高的核心业务如金融交易、用户资料外键是刚需在读多写少、可接受短暂不一致的场景如日志、统计报表可用应用层兜底。关键是权衡清楚你愿意为数据一致性付出多少性能和运维成本3. 约束的组合拳如何用最少的约束覆盖最复杂的业务场景3.1 CHECK约束MySQL 8.0的“业务逻辑翻译器”终于不用全靠应用层在MySQL 8.0.16之前CHECK约束形同虚设语法支持但不校验。现在它真正落地成为把业务规则直译成SQL的利器。比如一个商品表业务规则是“价格必须大于0且折扣率在0-100之间”CREATE TABLE products ( id BIGINT PRIMARY KEY, name VARCHAR(100) NOT NULL, price DECIMAL(10,2) NOT NULL CHECK (price 0), discount_rate TINYINT CHECK (discount_rate BETWEEN 0 AND 100), final_price DECIMAL(10,2) AS (price * (1 - discount_rate/100)) STORED );这里CHECK做了三件事price 0杜绝负价格如-99元discount_rate BETWEEN 0 AND 100防止输入150%这种荒谬折扣结合生成列final_price确保计算结果始终基于合规输入。注意CHECK表达式不能包含子查询、存储函数、参数化变量只能是确定性计算。但它能引用同一行的其他列如上例的price和discount_rate这是UNIQUE或NOT NULL做不到的。我用CHECK解决过一个棘手问题某活动系统要求“优惠券有效期必须晚于创建时间”。以前靠应用层判断但总有后台脚本绕过。加上CHECK后CREATE TABLE coupons ( id BIGINT PRIMARY KEY, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, expire_time DATETIME NOT NULL, CHECK (expire_time create_time) );现在任何试图INSERT ... expire_time2020-01-01的操作都会被数据库当场拒绝。而且CHECK是事务安全的——如果create_time由触发器生成CHECK会在触发器执行后校验确保最终值合规。3.2 复合约束用多个字段的组合锁死业务逻辑的“不可能三角”单一字段约束解决线性问题复合约束则应对立体规则。比如一个课程预约系统要求“同一学生在同一时间段只能预约一门课”。这涉及三个字段student_id、course_id、time_slot_id。单个字段都可重复学生可约多门课课程可被多人约时段可有多门课但三者组合必须唯一CREATE TABLE enrollments ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, course_id BIGINT NOT NULL, time_slot_id BIGINT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_student_slot (student_id, time_slot_id), FOREIGN KEY (student_id) REFERENCES students(id), FOREIGN KEY (course_id) REFERENCES courses(id), FOREIGN KEY (time_slot_id) REFERENCES time_slots(id) );这里UNIQUE KEY uk_student_slot (student_id, time_slot_id)是核心——它确保学生A在时段T1只能有一条记录无论课程是C1还是C2。如果学生A想约C1和C2在T1第二条INSERT会因唯一键冲突失败。复合约束的威力还体现在部分索引优化上。比如某文章表要求“已发布的文章slug必须唯一草稿状态的slug可重复”。MySQL不支持条件唯一索引但可以用GENERATED COLUMN曲线救国CREATE TABLE articles ( id BIGINT PRIMARY KEY, title VARCHAR(200), slug VARCHAR(100), status ENUM(draft,published) DEFAULT draft, slug_for_unique VARCHAR(100) AS (CASE WHEN status published THEN slug ELSE CONCAT(draft_, id) END) STORED, UNIQUE KEY uk_published_slug (slug_for_unique) );原理是当statuspublishedslug_for_unique等于slugUNIQUE生效当statusdraftslug_for_unique变成draft_123含主键必然唯一不干扰草稿。这样一行SQL就实现了业务层需要十几行代码才能做的判断。3.3 约束与索引的共生关系为什么删约束可能让查询变慢十倍新手常犯的错误是为了“优化”随手DROP INDEX或DROP CONSTRAINT。但约束和索引是深度绑定的。回顾前面的例子PRIMARY KEY→ 自动创建聚簇索引UNIQUE (col)→ 自动创建唯一索引FOREIGN KEY (col)→强烈建议为col单独建索引否则DELETE父表时子表需全表扫描找匹配行。我亲眼见过一个案例某团队为提升写入速度把订单表的FOREIGN KEY (user_id)删了理由是“应用层已校验”。结果一个月后运营要查“所有北京用户的订单”执行SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE cityBeijing)耗时从0.2秒飙升到15秒。原因删外键时顺手把user_id上的索引也删了IN子查询触发全表扫描而users表有千万级数据。所以删约束前务必先查它依赖的索引-- 查看orders表的所有索引 SHOW INDEX FROM orders; -- 查看约束定义 SELECT constraint_name, constraint_type FROM information_schema.table_constraints WHERE table_name orders AND table_schema your_db;如果FOREIGN KEY对应的列没有独立索引必须先CREATE INDEX idx_user_id ON orders(user_id)再删约束。否则你删掉的不是约束而是查询性能的基石。另一个隐藏关联是UNIQUE索引的列顺序直接影响查询效率。比如UNIQUE KEY uk_name_email (name, email)它能加速WHERE name ?和WHERE name ? AND email ?但无法加速WHERE email ?最左前缀原则。所以设计复合唯一键时要把高频查询条件放前面。曾有个用户表UNIQUE KEY uk_email_name (email, name)结果登录接口WHERE email ?走了全表扫描——改索引顺序后QPS从800飙到3200。4. 实战避坑指南那些文档里不写但老手都踩过的深坑4.1 字符集与排序规则Collation让UNIQUE失效的“幽灵杀手”这是最隐蔽、最让人抓狂的坑。假设你建了这样的表CREATE TABLE users ( id INT PRIMARY KEY, username VARCHAR(50) COLLATE utf8mb4_unicode_ci ); ALTER TABLE users ADD UNIQUE KEY uk_username (username);一切正常。直到某天用户注册admin和ADMIN数据库居然都接受了查SHOW INDEX FROM users索引明明存在。问题出在utf8mb4_unicode_ci的cicase insensitive上——它认为大小写不敏感admin和ADMIN被视为相同值UNIQUE应该报错才对不因为UNIQUE校验时也遵循排序规则admin ADMIN返回TRUE所以第二条INSERT被当作重复值拒绝……等等为什么没拒绝真相是utf8mb4_unicode_ci在比较时会将字符串标准化如转小写、忽略重音但UNIQUE索引的B树存储的是原始字节。当插入admin索引存admin插入ADMIN索引存ADMIN但校验时ADMIN被标准化为admin发现已存在于是报错。但如果你用的是utf8mb4_general_ci旧版它标准化规则不同可能导致cafe和café被当作相同——而你完全没意识到。解决方案只有两个明确业务需求用户名是否区分大小写如果不区分用COLLATE utf8mb4_bin二进制精确匹配建索引但应用层需统一转小写再存强制标准化在应用层或触发器里把username转为小写再INSERT索引用默认utf8mb4_0900_as_cs大小写敏感重音敏感确保物理存储和逻辑一致。我最后的选择是所有业务唯一字段用户名、邮箱、手机号统一用COLLATE utf8mb4_bin并在应用层做标准化邮箱转小写手机号去空格和-。这样UNIQUE索引100%可靠且避免了排序规则的黑盒行为。4.2 外键的“延迟检查”陷阱为什么TRUNCATE比DELETE更危险FOREIGN KEY默认是RESTRICT模式父表记录被删前必须确保子表无引用。但很多人不知道TRUNCATE TABLE会绕过外键检查比如CREATE TABLE parents (id INT PRIMARY KEY); CREATE TABLE children (id INT PRIMARY KEY, parent_id INT, FOREIGN KEY (parent_id) REFERENCES parents(id)); INSERT INTO parents VALUES (1); INSERT INTO children VALUES (1, 1); -- 这会报错Cannot delete or update a parent row DELETE FROM parents; -- 但这个会成功且children表数据还在变成孤儿 TRUNCATE TABLE parents;TRUNCATE是DDL操作它直接重建表不走事务日志也不触发外键约束检查。结果就是父表空了子表数据还在但parent_id全部指向不存在的ID——数据一致性瞬间崩塌。规避方法只有两个永远不要对有外键的父表用TRUNCATE改用DELETE FROM table虽然慢但安全如果真要清空先SET FOREIGN_KEY_CHECKS 0; TRUNCATE ...; SET FOREIGN_KEY_CHECKS 1;但必须确保清空后立即重建父表数据否则子表长期处于不一致状态。更狠的坑在ON UPDATE CASCADE。某次我们升级用户ID生成规则把BIGINT主键换成UUID执行UPDATE users SET id new_uuid WHERE id 1。由于ON UPDATE CASCADE所有orders.user_id也被自动更新。但问题来了orders.user_id是BIGINT类型而new_uuid是字符串MySQL尝试隐式转换把UUID转成0结果所有订单的user_id全变成0指向一个不存在的用户。血的教训ON UPDATE CASCADE只适用于同类型、可安全转换的字段否则宁可手动更新。4.3 约束命名规范为什么“sys_12345”会让你在凌晨三点被电话叫醒MySQL默认给约束起名如sys_12345这在开发环境无所谓但在线上运维时是灾难。某次线上事故订单表突然无法插入报错ERROR 1062: Duplicate entry xxx for key sys_12345。DBA查information_schema发现sys_12345对应UNIQUE KEY但不知道是哪个字段。翻Git历史发现三个月前有人改过表结构但约束名早被覆盖。最后靠SHOW CREATE TABLE orders逐行比对花了40分钟才定位到是email字段的唯一键冲突。从此我们定下铁律所有约束必须显式命名且名字符合业务语义。主键pk_table_name如pk_users唯一键uk_business_field如uk_users_email、uk_orders_order_no外键fk_child_parent_field如fk_orders_users_user_id检查约束chk_business_rule如chk_products_price_gt_zero。命名不仅是可读性更是可维护性。当ALTER TABLE需要删约束时-- 好一眼知道删的是什么 ALTER TABLE users DROP INDEX uk_users_email; -- 坏你得先查约束名 ALTER TABLE users DROP INDEX sys_12345;而且命名规范让团队协作零成本。新人看到fk_orders_users_user_id立刻明白这是订单表关联用户表的外键无需翻文档。4.4 性能监控如何用一条SQL揪出正在拖垮数据库的约束约束是守护者但也可能是瓶颈。当线上出现慢查询除了查索引还要查约束是否成了枷锁。以下SQL能快速定位问题-- 查看所有外键及其关联的索引 SELECT CONSTRAINT_NAME, COLUMN_NAME, REFERENCED_TABLE_NAME, REFERENCED_COLUMN_NAME, UPDATE_RULE, DELETE_RULE FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA your_db AND TABLE_NAME orders AND CONSTRAINT_NAME LIKE fk_%; -- 查看约束相关的锁等待需开启performance_schema SELECT OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME, COUNT_READ, COUNT_WRITE FROM performance_schema.table_io_waits_summary_by_index_usage WHERE OBJECT_SCHEMA your_db AND OBJECT_NAME IN (orders, users) ORDER BY COUNT_WRITE DESC;如果发现fk_orders_users_user_id的COUNT_WRITE异常高说明外键检查正在消耗大量I/O。这时就要评估是否真的需要实时强一致能否改为异步校验或者把user_id索引从BTREE换成HASH内存表我处理过一个高并发下单场景FOREIGN KEY (product_id)导致每秒插入下降30%。最终方案是保留外键声明保证数据逻辑正确但为product_id建HASH索引CREATE INDEX idx_product_hash ON orders(product_id) USING HASH并将innodb_lock_wait_timeout从50秒降到5秒让失败更快返回避免长事务堆积。5. 约束的演进与边界当MySQL不够用时你还能做什么5.1 约束的终极形态生成列Generated Column 索引实现动态业务规则MySQL 5.7引入的生成列让约束能力跃升一个维度。它允许你定义一个“虚拟列”其值由其他列计算得出并可为其建索引。比如一个搜索场景用户想按“城市拼音首字母”筛选但城市名是中文如“北京”、“上海”。传统做法是在应用层转拼音再存一列city_pinyin_first但容易不一致。用生成列一劳永逸CREATE TABLE users ( id BIGINT PRIMARY KEY, city VARCHAR(50), city_pinyin_first CHAR(1) AS (LEFT(CONVERT(city USING gbk), 1)) STORED, INDEX idx_city_pinyin (city_pinyin_first) );这里CONVERT(city USING gbk)将中文转GB编码LEFT(..., 1)取首字节GBK中汉字首字节即拼音首字母STORED表示物理存储。现在WHERE city_pinyin_first B能走索引且值永远与city同步无需应用层干预。更进一步结合CHECK约束可实现“智能默认值”。比如某配置表要求“启用状态默认为true但仅当类型为system时才允许false”CREATE TABLE configs ( id BIGINT PRIMARY KEY, type ENUM(system, user) NOT NULL, is_enabled BOOLEAN NOT NULL DEFAULT TRUE, CHECK ( (type system AND is_enabled IN (TRUE, FALSE)) OR (type user AND is_enabled TRUE) ) );这个CHECK确保user类型配置永远启用system类型可启可禁。它比应用层if-else更可靠且一次定义处处生效。5.2 约束的边界为什么有些规则数据库永远无法替代应用层必须清醒认识到约束是数据的“底线”不是业务的“天花板”。它能保证“不违法”但无法保证“最优”。比如“用户余额不能为负” →CHECK (balance 0)可控“用户今日提现总额不能超过5万元” → 需要聚合查询SUM(amount)约束无法实现“订单支付后库存必须实时扣减” → 涉及跨表更新需事务应用逻辑协调。这些场景约束只能做辅助在库存表加CHECK (stock 0)防超卖最后一单在订单表加FOREIGN KEY (product_id)确保扣减对象存在但核心的“扣减逻辑”和“幂等校验”必须由应用层用分布式锁事务实现。我的经验是画一张“数据校验金字塔”底层是数据库约束强制、高效、不可绕过中层是应用层服务校验灵活、可扩展、支持复杂逻辑顶层是前端校验用户体验、减少无效请求。三层各司其职缺一不可。试图用约束解决所有问题就像用锤子修手表——力气够大但精度全无。5.3 未来已来MySQL 8.0 的约束增强你该关注什么MySQL 8.0不是终点而是起点。值得关注的新动向角色基础的约束Role-based Constraints社区提案中允许按用户角色定义不同约束如管理员可绕过某些CHECK虽未落地但方向明确JSON字段的路径约束CHECK (JSON_CONTAINS_PATH(profile, one, $.age))让半结构化数据也能受约束保护并行约束检查针对大表ALTER TABLE加约束优化锁粒度减少业务影响。但比新特性更重要的是理念约束设计本质是领域驱动设计DDD在数据库层的投射。每一个NOT NULL、UNIQUE、FOREIGN KEY都是你对业务领域的一次建模。它要求你深入理解什么是实体什么是值对象它们之间有何关联规则边界在哪里所以下次写CREATE TABLE时别急着敲键盘。先拿出白板画出业务流程图标出所有“必须”“禁止”“唯一”“关联”的节点。然后再把它们一行行翻译成MySQL能懂的语言。这才是约束的真正力量——它不是语法而是你和数据世界签下的第一份契约。
阅读完成 · 觉得有帮助？
