今天就来唠唠“字段”这点事儿。别小看这俩字，我们天天跟它打交道，不管是搞数据库、写网页还是弄接口，都离不开它。
前段时间接手一个小项目，需要重新梳理一下用户信息的录入。需求那边就扔过来一堆信息项，说都要存起来。行，那就开始设计数据库表呗。
第一步：琢磨哪些是必须的
拿到那一堆字段列表，我第一个反应就是，哪些是必须有的，哪些是可有可无的？这事儿可不能马虎。你想，要是把一个很关键的信息设成“可空”，那录数据的人可能就真不给你填，回头数据分析或者别的功能要用的时候，抓瞎不是？
我就拿着列表，一项一项地过：
用户名？必须的，登录总得用。
手机号？现在基本都用手机号注册登录或者找回密码，必须的。
邮箱？这个嘛有的人可能没有，或者不想提供，那就先设成可选的。
昵称？用户可以自己起，也可以系统默认一个，后期再改，那就可选的。
注册时间？这个后台自动记录，必须的。
真实姓名？看场景，我们这个项目初期用不上，可选的。
身份证号？更敏感，初期肯定可选，甚至根本就先不加这个字段。
就这么一条条捋下来，心里大概有个谱。哪些字段在数据库里得设置成 `NOT NULL`（就是不能为空），哪些可以 `NULL`（就是允许空着）。
第二步：动手建表和写代码
思路理清，就开始干活。在数据库里建表，把决定好的“必须”字段都加上非空限制。然后就开始写录入信息的代码。
前端表单这块儿也得对应上。哪些是必填项，得在输入框旁边给个提示，比如加个星号啥的。提交的时候，也得加个校验，要是必填的没填，得拦住不让提交，还得告诉用户哪里没填对。
我当时就用浏览器自带的 `required` 属性，挺方便，能做个基本的前端校验。后端校验是绝对不能少的，前端校验用户是可以绕过去的，后端是一道保险，也得把必填字段的检查逻辑加上。
踩坑与调整
刚上线跑一阵，就发现问题。有个字段当时觉得不那么重要，设成“可选”。结果？业务流程走到后面某一步的时候，发现这个字段的数据是必须的，但好多用户当初就没填！这就麻烦，要么找用户补充，要么这个流程就卡住。
没办法，只能回头改。先把数据库那个字段改成 `NOT NULL`，但直接改会报错，因为表里已经存在这个字段是空的数据。得先写个脚本，把现有数据里这个字段为空的，给它填个默认值或者想办法补上，然后再去改表结构，把它设成非空。
前端和后端的代码也得跟着调整，把这个字段从“可选”变成“必填”，校验逻辑、提示信息都得加上。
还有一次是反过来，有个字段一开始觉得特别重要，设成“必填”。结果用户反馈说，他们就是没有这个信息，或者这个信息对他们来说是隐私，不想提供。这就导致用户没法完成注册或者信息录入，影响体验。
后来跟产品那边沟通好几次，评估下来发现这个字段确实不是所有场景下都绝对需要。还是把它改回“可选”，也加些说明，告诉用户如果提供这个信息，能获得什么额外的好处或者服务，引导用户填写。
我的体会
搞这么几次下来，我算是明白，字段这东西，看着简单，学问不少。定义一个字段是“必填”还是“可选”，不是拍脑袋决定的。
你得想清楚：
这个信息是不是核心业务流程绝对依赖的？
用户是不是一定有这个信息？用户愿不愿意提供？
设成必填会不会挡住用户？设成可选会不会导致后续数据没法用？
性能上的考虑有时候也得掂量掂量，虽然大部分时候这点性能差异不是主要矛盾。
说白，就是要结合业务场景和用户体验来综合判断。一开始想不清楚，宁可先保守一点，别把话说死，等跑起来看情况再调整。最好的还是在设计阶段就多花点时间琢磨透，省得后面反复修改，费时费力。
反正我现在的习惯是，拿到字段列表，先不急着动手，多问几个为什么，多考虑几种情况，把必填和可选的依据想扎实，再开始搞数据库和代码。