面试必问胸罩杯计算逻辑：3个坑让你代码跑不通
刚入职的新人最怕什么？不是业务逻辑复杂，而是复制来的代码跑不通不知道怎么调。特别是处理那些看似简单实则暗藏玄机的字段，比如电商后台的“胸罩杯”尺码映射。这玩意儿在Java、Python后端开发中是高频场景，也是面试必问的边界条件处理题。
很多同事直接Copy网上的枚举类或映射表，结果一上生产环境就炸：有的用户选了“75B”，系统算出库存是空的；有的用户选了“34C”，前端显示的是乱码。为什么？因为你没搞懂“胸罩杯”这个字段在底层数据结构里的真实含义。它不是一个简单的字符串，而是一个由“下围”和“罩杯”组成的复合键，且存在多套标准（国标、英标、美标）混用的情况。
今天我们就把“胸罩杯”这个看似 trivial 的业务字段拆开揉碎，看看那些资深开发踩过的大坑。
坑一：混淆“下围”与“码数”，导致映射失败
现象
前端传来 size: 75B，后端去查库存表 stock_75B，查不到。或者前端传来 size: M，后端报错 NumberFormatException。
根本原因
“胸罩杯”的表示方法有几种：英标/国标数字型：75B, 80C（75代表下围厘米数，B代表罩杯）。
字母型：S, M, L, XL（通常对应不同的下围和罩杯组合，但这套映射在不同品牌、不同地区标准不一）。
美标：34B, 36C（英寸制，1英寸≈2.54cm，所以34英寸≈86cm，接近国标的85/90之间）。很多开发者直接把 size 当作唯一键去查库，忽略了**“同一物理尺寸在不同标准下有不同的字符串表示”**。比如，国标的 75B 在美标里可能对应 34B 或 34C（取决于具体品牌的换算系数），而在字母标里可能对应 S 或 M。
更坑的是，有些旧系统为了兼容，把 75 存成了整型，把 B 存成了字符型。当前端传来 75 B（中间有空格）或者 75b（小写）时，简单的 equals 匹配就挂了。
正确写法对比
错误写法（硬编码映射，无标准化）：
// Java 示例
public String getStockCode(String sizeInput) {// 坑1：直接拼接，没处理空格和大小写// 坑2：只支持国标，美标用户进来直接nullif (sizeInput == null) return null;// 这种if-else链条是维护噩梦if (sizeInput.equals(75B)) {return SKU_75_B_STANDARD;} else if (sizeInput.equals(80C)) {return SKU_80_C_STANDARD;} else if (sizeInput.equals(34B)) { // 试图支持美标，但没做单位换算return SKU_34_B_US; }// 没匹配到就返回空，导致库存查询失败return null;
}正确写法（统一内部模型，标准化输入）：
// Java 示例
import java.util.Map;
import java.util.HashMap;
import java.util.regex.Pattern;
import java.util.regex.Matcher;public class BraSizeNormalizer {// 内部标准：统一转为 下围(cm)_罩杯 格式，如 75_B// 这样库存表只存一种格式，彻底解耦前端展示格式private static final Pattern SIZE_PATTERN = Pattern.compile(^\\s*(\\d{2,3})\\s*([A-F])\\s*$, Pattern.CASE_INSENSITIVE);// 预定义的美标到国标的近似映射（实际业务中需根据品牌配置）private static final MapInteger, Integer US_TO_CN_UNDERBUST = Map.of(32, 70,34, 75,36, 80,38, 85,40, 90);public String normalizeToInternalKey(String rawSize) {if (rawSize == null || rawSize.trim().isEmpty()) {throw new IllegalArgumentException(Size cannot be empty);}String cleaned = rawSize.trim().toUpperCase();// 1. 尝试匹配数字+字母格式 (如 75B, 34B)Matcher matcher = SIZE_PATTERN.matcher(cleaned);if (matcher.matches()) {String underbustStr = matcher.group(1);String cup = matcher.group(2);int underbust = Integer.parseInt(underbustStr);// 判断是美标还是国标// 经验法则：国标下围通常在 65-100 之间，美标在 30-45 之间if (underbust = 30 underbust = 45) {// 假设是美标，转换为国标近似值Integer cnUnderbust = US_TO_CN_UNDERBUST.get(underbust);if (cnUnderbust != null) {underbust = cnUnderbust;}// 如果找不到精确映射，可以取最接近的，这里简化处理}return underbust + _ + cup; // 返回 75_B}// 2. 如果是字母型 S/M/L，需要额外的配置表映射，此处略// 3. 如果格式不对，抛异常而不是静默失败throw new IllegalArgumentException(Invalid size format: + rawSize);}
}复现与修复
在本地起一个Postman，分别发送 75B, 75 b, 75B, 34B。错误写法：75 b 和 75B 都会返回 null，34B 返回错误的SKU。
正确写法：全部归一化为 75_B 或 75_B（34转75），库存查询稳定命中。规避建议
永远不要信任前端的字符串格式。 在网关层或Service层入口处，必须有一个“标准化器（Normalizer）”。将外部世界五花八门的输入（英标、美标、字母标、带空格、大小写混乱）统一转换成你内部数据库只认的一种“Canonical Format”。库存表里只存这种内部格式。
坑二：忽略“半码”与“非标”尺码，边界条件崩溃
现象
用户选择了 75B+ 或者 80-75 这种非标尺码（某些大码品牌或定制业务存在），后端直接抛出异常或存入脏数据。
根本原因
“胸罩杯”虽然主流是整数下围+单字母罩杯，但现实中存在：半码下围：如 75.5，虽然少见，但在定制系统中存在。
非标罩杯：如 AA, G, H 甚至 I。很多开发者只写了 A, B, C, D, E, F，一旦用户选 AA 或 G，正则匹配失败或枚举找不到。
组合码：有些品牌用 30/70 这种双标识。正确写法对比
错误写法（枚举硬编码）：
# Python 示例
from enum import Enumclass CupSize(Enum):A = 'A'B = 'B'C = 'C'D = 'D'E = 'E'F = 'F'def parse_size(size_str: str):# 坑：只支持 A-F，不支持 AA, G 等# 坑：没处理下围是小数的情况if not size_str:return Nonecup_part = size_str[-1]underbust_part = size_str[:-1]try:underbust = int(underbust_part) # 如果是 75.5，这里直接崩cup_enum = CupSize(cup_part) # 如果是 'AA'，这里 KeyErrorexcept (ValueError, KeyError):return None # 静默吞掉错误，导致前端显示未知return f{underbust}_{cup_enum.value}正确写法（正则白名单 + 宽松解析）：
# Python 示例
import re# 正则：匹配 1-3位数字(可带一位小数) + 1-2位大写字母
# 注意：罩杯可能是单字母(A-F)或双字母(AA, DD等)，这里放宽到2位字母
SIZE_REGEX = re.compile(r'^(\d{1,3}(?:\.\d)?)\s*([A-F]{1,2})$')def parse_size_robust(size_str: str):if not size_str:raise ValueError(Size is required)# 清理空格，统一大写cleaned = size_str.strip().upper()match = SIZE_REGEX.match(cleaned)if not match:# 记录日志，方便排查是哪个奇葩格式进来的# logger.warning(fUnparsed size format: {size_str})raise ValueError(fInvalid size format: {size_str})underbust_str, cup_str = match.groups()# 统一转为浮点数存储或处理，避免精度问题underbust = float(underbust_str)# 业务逻辑：如果下围是整数，去掉小数点，保持库存Key的一致性# 例如 75.0 - 75, 75.5 - 75_5 (需与DB Schema一致)if underbust.is_integer():underbust_key = str(int(underbust))else:underbust_key = str(underbust)return f{underbust_key}_{cup_str}# 测试用例
# print(parse_size_robust(75B)) # 75_B
# print(parse_size_robust(80 AA)) # 80_AA
# print(parse_size_robust(75.5 C)) # 75_5_C复现与修复
用 Postman 发送 80 AA。错误写法：Python 会抛 KeyError: 'AA'，Java 会抛 IllegalArgumentException。
正确写法：正常返回 80_AA，并能在库存表中找到对应的记录（假设库存表支持 AA）。规避建议
正则表达式是处理非结构化文本的最佳朋友，但白名单思维更重要。 不要试图用 int() 或 parse() 去硬解，而是先用正则验证格式是否合法，再提取字段。对于罩杯字母，不要硬编码 A-F，要用 [A-Z]{1,2} 这种更宽泛的模式，然后在业务层判断该字母是否在“当前支持范围”内。如果不支持，应该返回明确的业务错误码（如 SIZE_NOT_SUPPORTED），而不是 500 错误。
坑三：多语言环境下的字符编码与排序陷阱
现象
在国际化（i18n）项目中，用户用德语或法语访问，前端传来的尺码格式可能带有特殊字符，或者数据库排序时，75B 和 75 C 的顺序不对，导致前端下拉框乱序。
根本原因编码问题：虽然尺码通常是 ASCII，但如果前端为了展示美观，传了 75B® 或者全角字符 ７５Ｂ，后端没做 Unicode 标准化。
排序问题：字符串排序是按 ASCII 码位。75B 75 C（因为空格 ASCII 32 'B' 66）？不对，75B 和 75 C 比较，第三个字符 B vs （空格），空格小，所以 75 C 排在 75B 前面。这不符合人类直觉（75B 应该在前）。
MDN Web Docs 参考：根据 MDN Web Docs 关于 String.prototype.localeCompare 的文档，字符串比较应使用 localeCompare 而非 == 或 ，以正确处理不同语言环境的排序规则。但在数据库层面，我们需要的是确定性的排序键。正确写法对比
错误写法（直接存字符串，依赖DB默认排序）：
-- 数据库表结构
CREATE TABLE bra_stock (id BIGINT PRIMARY KEY,size_key VARCHAR(20) NOT NULL, -- 存 75B, 75 C, 80Astock INT DEFAULT 0
);-- 查询时直接 order by size_key
SELECT * FROM bra_stock WHERE category = 'WOMEN' ORDER BY size_key ASC;结果：75 C 排在 75B 前面，80A 排在 75B 后面（因为 '8' '7'），但 75.5B 如果存为字符串，排序会非常混乱。
正确写法（分离排序字段 + Unicode 标准化）：
// Java 后端：生成排序用的数字字段
public class BraSizeDTO {private String sizeKey; // 内部Key: 75_Bprivate int underbustSort; // 下围数值，用于排序private int cupSort; // 罩杯数值，A=1, B=2, ... AA=0? 需自定义映射// 构造函数中计算public BraSizeDTO(String internalKey) {this.sizeKey = internalKey;// 解析 75_BString[] parts = internalKey.split(_);this.underbustSort = (int) Double.parseDouble(parts[0]);this.cupSort = calculateCupSort(parts[1]);}private int calculateCupSort(String cup) {// 自定义排序权重，确保 AA A B C D E F// 实际业务中可能更复杂MapString, Integer cupWeights = Map.of(AA, 1, A, 2, B, 3, C, 4, D, 5, E, 6, F, 7);return cupWeights.getOrDefault(cup, 99);}
}-- 数据库表结构优化
CREATE TABLE bra_stock (id BIGINT PRIMARY KEY,size_key VARCHAR(20) NOT NULL UNIQUE,underbust_sort INT NOT NULL,cup_sort INT NOT NULL,stock INT DEFAULT 0
);-- 创建复合索引，加速排序查询
CREATE INDEX idx_sort ON bra_stock (underbust_sort, cup_sort);-- 查询时按数字字段排序
SELECT * FROM bra_stock WHERE category = 'WOMEN' ORDER BY underbust_sort ASC, cup_sort ASC;复现与修复
插入数据：75B, 75 C, 80A, 75AA。错误写法（字符串排序）：75 C, 75AA, 75B, 80A （乱序）。
正确写法（数字排序）：75AA (Sort: 75, 1), 75B (Sort: 75, 3), 75 C (Sort: 75, 3? 需注意空格处理，建议清洗后无空格 75C Sort: 75, 4), 80A (Sort: 80, 2)。
注：为了简化，内部Key建议统一无空格，如 75C。规避建议
展示字段与存储/排序字段分离。 用户看到的 75B 是展示字段，数据库里存的 size_key 也是 75B，但用于排序的 underbust_sort 和 cup_sort 必须是数值型。这样无论前端怎么展示、怎么国际化，后端的排序逻辑都是稳定且高效的。同时，记得在入库前对字符串做 trim() 和 toUpperCase()，消除全角/半角、大小写差异。
总结与进阶
“胸罩杯”这个字段，看似简单，实则涉及数据标准化、边界条件处理、多语言兼容、数据库设计等多个维度。标准化：入口统一清洗，出口统一格式。
鲁棒性：正则白名单，拒绝静默失败，异常要抛出。
性能：排序字段数值化，避免字符串比较。
可维护性：映射关系配置化，不要硬编码在代码里。你在实际项目中，是不是也遇到过类似的“看似简单实则坑多”的字段？比如“身份证号”的校验、“手机号”的区号处理？你公司项目里是怎么处理的？欢迎在评论区分享你的踩坑经验或解决方案。 面试必问胸罩杯计算逻辑：3个坑让你代码跑不通
面试必问胸罩杯计算逻辑：3个坑让你代码跑不通
刚入职的新人最怕什么？不是业务逻辑复杂，而是复制来的代码跑不通不知道怎么调。特别是处理那些看似简单实则暗藏玄机的字段，比如电商后台的“胸罩杯”尺码映射。这玩意儿在Java、Python后端开发中是高频场景，也是面试必问的边界条件处理题。
很多同事直接Copy网上的枚举类或映射表，结果一上生产环境就炸：有的用户选了“75B”，系统算出库存是空的；有的用户选了“34C”，前端显示的是乱码。为什么？因为你没搞懂“胸罩杯”这个字段在底层数据结构里的真实含义。它不是一个简单的字符串，而是一个由“下围”和“罩杯”组成的复合键，且存在多套标准（国标、英标、美标）混用的情况。
今天我们就把“胸罩杯”这个看似 trivial 的业务字段拆开揉碎，看看那些资深开发踩过的大坑。
坑一：混淆“下围”与“码数”，导致映射失败
现象
前端传来 size: 75B，后端去查库存表 stock_75B，查不到。或者前端传来 size: M，后端报错 NumberFormatException。
根本原因
“胸罩杯”的表示方法有几种：英标/国标数字型：75B, 80C（75代表下围厘米数，B代表罩杯）。
字母型：S, M, L, XL（通常对应不同的下围和罩杯组合，但这套映射在不同品牌、不同地区标准不一）。
美标：34B, 36C（英寸制，1英寸≈2.54cm，所以34英寸≈86cm，接近国标的85/90之间）。很多开发者直接把 size 当作唯一键去查库，忽略了**“同一物理尺寸在不同标准下有不同的字符串表示”**。比如，国标的 75B 在美标里可能对应 34B 或 34C（取决于具体品牌的换算系数），而在字母标里可能对应 S 或 M。
更坑的是，有些旧系统为了兼容，把 75 存成了整型，把 B 存成了字符型。当前端传来 75 B（中间有空格）或者 75b（小写）时，简单的 equals 匹配就挂了。
正确写法对比
错误写法（硬编码映射，无标准化）：
// Java 示例
public String getStockCode(String sizeInput) {// 坑1：直接拼接，没处理空格和大小写// 坑2：只支持国标，美标用户进来直接nullif (sizeInput == null) return null;// 这种if-else链条是维护噩梦if (sizeInput.equals(75B)) {return SKU_75_B_STANDARD;} else if (sizeInput.equals(80C)) {return SKU_80_C_STANDARD;} else if (sizeInput.equals(34B)) { // 试图支持美标，但没做单位换算return SKU_34_B_US; }// 没匹配到就返回空，导致库存查询失败return null;
}正确写法（统一内部模型，标准化输入）：
// Java 示例
import java.util.Map;
import java.util.HashMap;
import java.util.regex.Pattern;
import java.util.regex.Matcher;public class BraSizeNormalizer {// 内部标准：统一转为 下围(cm)_罩杯 格式，如 75_B// 这样库存表只存一种格式，彻底解耦前端展示格式private static final Pattern SIZE_PATTERN = Pattern.compile(^\\s*(\\d{2,3})\\s*([A-F])\\s*$, Pattern.CASE_INSENSITIVE);// 预定义的美标到国标的近似映射（实际业务中需根据品牌配置）private static final MapInteger, Integer US_TO_CN_UNDERBUST = Map.of(32, 70,34, 75,36, 80,38, 85,40, 90);public String normalizeToInternalKey(String rawSize) {if (rawSize == null || rawSize.trim().isEmpty()) {throw new IllegalArgumentException(Size cannot be empty);}String cleaned = rawSize.trim().toUpperCase();// 1. 尝试匹配数字+字母格式 (如 75B, 34B)Matcher matcher = SIZE_PATTERN.matcher(cleaned);if (matcher.matches()) {String underbustStr = matcher.group(1);String cup = matcher.group(2);int underbust = Integer.parseInt(underbustStr);// 判断是美标还是国标// 经验法则：国标下围通常在 65-100 之间，美标在 30-45 之间if (underbust = 30 underbust = 45) {// 假设是美标，转换为国标近似值Integer cnUnderbust = US_TO_CN_UNDERBUST.get(underbust);if (cnUnderbust != null) {underbust = cnUnderbust;}// 如果找不到精确映射，可以取最接近的，这里简化处理}return underbust + _ + cup; // 返回 75_B}// 2. 如果是字母型 S/M/L，需要额外的配置表映射，此处略// 3. 如果格式不对，抛异常而不是静默失败throw new IllegalArgumentException(Invalid size format: + rawSize);}
}复现与修复
在本地起一个Postman，分别发送 75B, 75 b, 75B, 34B。错误写法：75 b 和 75B 都会返回 null，34B 返回错误的SKU。
正确写法：全部归一化为 75_B 或 75_B（34转75），库存查询稳定命中。规避建议
永远不要信任前端的字符串格式。 在网关层或Service层入口处，必须有一个“标准化器（Normalizer）”。将外部世界五花八门的输入（英标、美标、字母标、带空格、大小写混乱）统一转换成你内部数据库只认的一种“Canonical Format”。库存表里只存这种内部格式。
坑二：忽略“半码”与“非标”尺码，边界条件崩溃
现象
用户选择了 75B+ 或者 80-75 这种非标尺码（某些大码品牌或定制业务存在），后端直接抛出异常或存入脏数据。
根本原因
“胸罩杯”虽然主流是整数下围+单字母罩杯，但现实中存在：半码下围：如 75.5，虽然少见，但在定制系统中存在。
非标罩杯：如 AA, G, H 甚至 I。很多开发者只写了 A, B, C, D, E, F，一旦用户选 AA 或 G，正则匹配失败或枚举找不到。
组合码：有些品牌用 30/70 这种双标识。正确写法对比
错误写法（枚举硬编码）：
# Python 示例
from enum import Enumclass CupSize(Enum):A = 'A'B = 'B'C = 'C'D = 'D'E = 'E'F = 'F'def parse_size(size_str: str):# 坑：只支持 A-F，不支持 AA, G 等# 坑：没处理下围是小数的情况if not size_str:return Nonecup_part = size_str[-1]underbust_part = size_str[:-1]try:underbust = int(underbust_part) # 如果是 75.5，这里直接崩cup_enum = CupSize(cup_part) # 如果是 'AA'，这里 KeyErrorexcept (ValueError, KeyError):return None # 静默吞掉错误，导致前端显示未知return f{underbust}_{cup_enum.value}正确写法（正则白名单 + 宽松解析）：
# Python 示例
import re# 正则：匹配 1-3位数字(可带一位小数) + 1-2位大写字母
# 注意：罩杯可能是单字母(A-F)或双字母(AA, DD等)，这里放宽到2位字母
SIZE_REGEX = re.compile(r'^(\d{1,3}(?:\.\d)?)\s*([A-F]{1,2})$')def parse_size_robust(size_str: str):if not size_str:raise ValueError(Size is required)# 清理空格，统一大写cleaned = size_str.strip().upper()match = SIZE_REGEX.match(cleaned)if not match:# 记录日志，方便排查是哪个奇葩格式进来的# logger.warning(fUnparsed size format: {size_str})raise ValueError(fInvalid size format: {size_str})underbust_str, cup_str = match.groups()# 统一转为浮点数存储或处理，避免精度问题underbust = float(underbust_str)# 业务逻辑：如果下围是整数，去掉小数点，保持库存Key的一致性# 例如 75.0 - 75, 75.5 - 75_5 (需与DB Schema一致)if underbust.is_integer():underbust_key = str(int(underbust))else:underbust_key = str(underbust)return f{underbust_key}_{cup_str}# 测试用例
# print(parse_size_robust(75B)) # 75_B
# print(parse_size_robust(80 AA)) # 80_AA
# print(parse_size_robust(75.5 C)) # 75_5_C复现与修复
用 Postman 发送 80 AA。错误写法：Python 会抛 KeyError: 'AA'，Java 会抛 IllegalArgumentException。
正确写法：正常返回 80_AA，并能在库存表中找到对应的记录（假设库存表支持 AA）。规避建议
正则表达式是处理非结构化文本的最佳朋友，但白名单思维更重要。 不要试图用 int() 或 parse() 去硬解，而是先用正则验证格式是否合法，再提取字段。对于罩杯字母，不要硬编码 A-F，要用 [A-Z]{1,2} 这种更宽泛的模式，然后在业务层判断该字母是否在“当前支持范围”内。如果不支持，应该返回明确的业务错误码（如 SIZE_NOT_SUPPORTED），而不是 500 错误。
坑三：多语言环境下的字符编码与排序陷阱
现象
在国际化（i18n）项目中，用户用德语或法语访问，前端传来的尺码格式可能带有特殊字符，或者数据库排序时，75B 和 75 C 的顺序不对，导致前端下拉框乱序。
根本原因编码问题：虽然尺码通常是 ASCII，但如果前端为了展示美观，传了 75B® 或者全角字符 ７５Ｂ，后端没做 Unicode 标准化。
排序问题：字符串排序是按 ASCII 码位。75B 75 C（因为空格 ASCII 32 'B' 66）？不对，75B 和 75 C 比较，第三个字符 B vs （空格），空格小，所以 75 C 排在 75B 前面。这不符合人类直觉（75B 应该在前）。
MDN Web Docs 参考：根据 MDN Web Docs 关于 String.prototype.localeCompare 的文档，字符串比较应使用 localeCompare 而非 == 或 ，以正确处理不同语言环境的排序规则。但在数据库层面，我们需要的是确定性的排序键。正确写法对比
错误写法（直接存字符串，依赖DB默认排序）：
-- 数据库表结构
CREATE TABLE bra_stock (id BIGINT PRIMARY KEY,size_key VARCHAR(20) NOT NULL, -- 存 75B, 75 C, 80Astock INT DEFAULT 0
);-- 查询时直接 order by size_key
SELECT * FROM bra_stock WHERE category = 'WOMEN' ORDER BY size_key ASC;结果：75 C 排在 75B 前面，80A 排在 75B 后面（因为 '8' '7'），但 75.5B 如果存为字符串，排序会非常混乱。
正确写法（分离排序字段 + Unicode 标准化）：
// Java 后端：生成排序用的数字字段
public class BraSizeDTO {private String sizeKey; // 内部Key: 75_Bprivate int underbustSort; // 下围数值，用于排序private int cupSort; // 罩杯数值，A=1, B=2, ... AA=0? 需自定义映射// 构造函数中计算public BraSizeDTO(String internalKey) {this.sizeKey = internalKey;// 解析 75_BString[] parts = internalKey.split(_);this.underbustSort = (int) Double.parseDouble(parts[0]);this.cupSort = calculateCupSort(parts[1]);}private int calculateCupSort(String cup) {// 自定义排序权重，确保 AA A B C D E F// 实际业务中可能更复杂MapString, Integer cupWeights = Map.of(AA, 1, A, 2, B, 3, C, 4, D, 5, E, 6, F, 7);return cupWeights.getOrDefault(cup, 99);}
}-- 数据库表结构优化
CREATE TABLE bra_stock (id BIGINT PRIMARY KEY,size_key VARCHAR(20) NOT NULL UNIQUE,underbust_sort INT NOT NULL,cup_sort INT NOT NULL,stock INT DEFAULT 0
);-- 创建复合索引，加速排序查询
CREATE INDEX idx_sort ON bra_stock (underbust_sort, cup_sort);-- 查询时按数字字段排序
SELECT * FROM bra_stock WHERE category = 'WOMEN' ORDER BY underbust_sort ASC, cup_sort ASC;复现与修复
插入数据：75B, 75 C, 80A, 75AA。错误写法（字符串排序）：75 C, 75AA, 75B, 80A （乱序）。
正确写法（数字排序）：75AA (Sort: 75, 1), 75B (Sort: 75, 3), 75 C (Sort: 75, 3? 需注意空格处理，建议清洗后无空格 75C Sort: 75, 4), 80A (Sort: 80, 2)。
注：为了简化，内部Key建议统一无空格，如 75C。规避建议
展示字段与存储/排序字段分离。 用户看到的 75B 是展示字段，数据库里存的 size_key 也是 75B，但用于排序的 underbust_sort 和 cup_sort 必须是数值型。这样无论前端怎么展示、怎么国际化，后端的排序逻辑都是稳定且高效的。同时，记得在入库前对字符串做 trim() 和 toUpperCase()，消除全角/半角、大小写差异。
总结与进阶
“胸罩杯”这个字段，看似简单，实则涉及数据标准化、边界条件处理、多语言兼容、数据库设计等多个维度。标准化：入口统一清洗，出口统一格式。
鲁棒性：正则白名单，拒绝静默失败，异常要抛出。
性能：排序字段数值化，避免字符串比较。
可维护性：映射关系配置化，不要硬编码在代码里。你在实际项目中，是不是也遇到过类似的“看似简单实则坑多”的字段？比如“身份证号”的校验、“手机号”的区号处理？你公司项目里是怎么处理的？欢迎在评论区分享你的踩坑经验或解决方案。