1. 先定位这个null到底是从哪一层冒出来的1.1 后端产出的null数据库空值、ORM映射与聚合函数接手过中后台项目的人都懂一个规律线上95%的前端白屏事故最后都能在一堆报错里翻到一个关键词——null。而最常见的场景就是前端接收结果列表时列表里某个字段值是null页面渲染或者逻辑处理直接崩了。我先说一句可能很多人不爱听的话null不是bug是常态。只要数据库字段允许为空、只要查询结果可能没有匹配行、只要上游系统传参有缺省后端就一定会返回null。防不住也没必要防你要做的是先搞清楚这个null是哪一层冒出来的。我用一个真实例子来说明。项目里有个订单列表接口后端返回的数据结构大概是这样的{ code: 0, data: { list: [ { orderId: A10001, customerName: 张三, amount: 199.00, remark: null, createTime: 2024-03-18 10:22:00 }, { orderId: A10002, customerName: null, amount: null, remark: 加急处理, createTime: null } ] } }注意第二行数据customerName、amount、createTime全是null。这种数据是怎么来的我拆开说数据库字段本身允许NULL比如customer_name VARCHAR(50) NULL如果下单时没记录客户名查出来就是NULL。LEFT JOIN 右表无匹配订单表左连接客户表如果客户信息被删了或者关联ID对不上那么连出来的customer_name就是NULL。聚合查询的经典坑用COUNT、SUM、AVG做统计时如果没有匹配行很多数据库返回的结果不是一个数字而是NULL。有些后端同学直接用sum(...)映射到totalAmount字段前端拿到totalAmount: null是很正常的事。热搜词里那个group by 多个字段的场景多半也是这个套路——分组统计的别名字段一旦没匹配行就是null。ORM框架的默认映射Java的MyBatis、Golang的GORM当查询结果中某列没有值结构体里对应的字段默认就是零值或者nil。如果后端忘了设置默认值JSON序列化时就是null。所以当你发现列表里某个字段是null第一步不是打开编辑器写防御代码而是先问后端一句这个字段在什么业务场景下会是null是允许为空还是数据异常这两种情况的处理策略完全不同。1.2 序列化与网络传输null在JSON里是怎么保命的如果说数据库和ORM决定了null的出生那JSON序列化则决定了null的长相。这里有个巨坑同一个null在不同的后端序列化配置下到前端手里可能是完全不同的形态。我用Java生态举几个例子前端同学不一定写后端但至少要看得懂接口返回序列化方案null字段默认输出说明JacksonSpring Boot默认field: null保留字段名值为nullJackson NON_NULL配置字段直接消失JSON里根本没有这个keyGsonfield: null默认保留Fastjsonfield: null默认保留部分版本行为不一致Golangencoding/jsonfield: null指针类型为nil时输出nullGolangomitempty字段直接消失结构体标签控制这个区别对前端影响巨大。如果后端开了NON_NULL你前端写if (res.data.remark null)是永远不成立的因为remark这个key压根不存在取出来的值是undefined而不是null。很多前端新手就在这里栽跟头明明接口文档说这个字段可能为null代码里判断了 null结果走了else分支逻辑全错。所以在前端处理null之前我先给一个建议在浏览器Network面板里看接口的实际返回JSON而不是只看接口文档。你要先确认三件事这个字段是field: null还是 key 直接消失这个字段的值是所有行都null还是部分行为null列表外层字段比如data.list本身有没有可能也是null第三点极其重要。太多人只盯着列表里的字段忽略了list本身也可能为null。后端返回list: null和返回list: []是两种完全不同的心境——前者会让你的res.data.list.map(...)直接抛异常后者则安静如鸡。1.3 拿到第一手数据先别急着修先判断null的性质排查null问题时我养成了一个固定习惯把接口返回的JSON扔到编辑器的格式化工具里全局搜索null然后逐个判断每个null的性质。这一步对后面写代码帮助极大。判断方法也很简单对着字段问三个问题这个字段在业务上允许为空吗比如订单的备注字段空是常态前端显示空白或暂无备注就好不需要任何特殊逻辑。这个字段为空会破坏后续计算吗比如金额、数量、日期如果后续要做排序、加总、格式化null就会引发连锁反应。这个字段为空会影响页面主流程吗比如用户头像、商品主图图片类字段是null前端如果直接丢给img的src会出现裂图或者转圈需要降级成默认图。我自己在做项目梳理时会给每个字段打一个标签safe-null、danger-null、critical-null。safe-null是备注、描述这类纯展示文本danger-null是参与计算、排序、拼接的字段critical-null是一旦为null整个页面或模块就无法工作的字段。这样定位问题、写防御代码时心里就有了一张地图而不是每次都在代码里临时打补丁。2. 模板与表格组件null在渲染层的真实破坏力2.1 插值、v-model与v-for哪些情况会崩哪些只会留白先说结论在Vue模板里直接插值一个null字段页面不会崩它会被渲染成空字符串。比如span{{ item.customerName }}/span当customerName为null时页面显示空白浏览器不会报警。真正会报错的是下面这些场景span{{ item.customerName.toUpperCase() }}/span span{{ item.userInfo.age }}/span span :titleitem.remark.substring(0, 10){{ item.remark }}/span这三个例子分别代表了三种崩溃模式直接调用方法null没有toUpperCase方法运行时抛Cannot read properties of null (reading toUpperCase)。深层属性访问item.userInfo为null再去读.age报Cannot read properties of null (reading age)。方法链访问item.remark.substring(0, 10)remark为null直接崩。有意思的是如果item.userInfo本身是null模板里的{{ item.userInfo.age }}不会白屏而是渲染成空。因为Vue的模板编译器对深层属性访问做了容错处理读不到值就返回undefined最终显示为空。但如果你在计算属性、watcher或methods里写同样的代码那就不客气了直接抛异常。再说v-for。v-foritem in list如果list是nullVue2和Vue3都不会报错渲染结果为空。但是v-for里的:keyitem.id如果id是null虽然不报错但key全是null会导致列表复用逻辑错乱可能出现勾选状态错位、动画不更新、编辑弹窗内容串行等问题。v-model的场景也值得注意。如果绑定值是nullinput v-modelitem.customerName会显示空输入框用户一输入字段就从null变成字符串。这个行为看似正常但在表单回显场景下有个隐患你无法区分用户清空了输入框和字段本来就是null提交时可能把原本的非空字段改成了空字符串。所以表单类需求我一般会跟产品确认字段为空时提交null还是空串两者在后端存储和查询时的语义完全不同。2.2 表格组件的连环坑el-table、vxe-table整列空白与formatter崩溃如果说模板插值是毛毛雨那表格组件就是雷暴区。我在实际项目里用el-table和vxe-table都踩过坑列出最典型的几种现场第一个坑整列空白。表格某列的字段在所有行里都是null时列会直接显示成空白。用户看到的效果是这一列消失了一样但表头还在。产品会问为什么这一列全是空的排查代码发现是后端没返回数据或者字段名对不上。这个问题不报错却非常致命——它会让用户以为是页面bug但其实是你和后端的字段契约没对齐。第二个坑formatter函数里null直接崩。很多人会在表格列配置里写formatter// 伪代码金额格式化 formatter: (row) { return row.amount.toFixed(2); // amount为null时直接崩溃 }null没有toFixed、substring、replace、split这些方法formatter一执行就抛异常表格要么整页白屏要么这一列全部渲染失败。vxe-table在某些版本里还会把这个异常吞掉表现为表格渲染到一半卡住。第三个坑排序时null的位置。给amount字段加排序如果某行的amount: null默认排序行为是null被排到最前面升序或者最后面降序取决于组件实现。有时候产品要求null永远排在最后这时候你需要自定义排序函数const compareAmount (a, b) { if (a.amount null) return 1; // null永远排到最后 if (b.amount null) return -1; return a.amount - b.amount; };第四个坑tooltip显示null字符串。表格列开了show-overflow-tooltip当字段值是null时鼠标悬停显示的工具提示是null这个字符串而不是空白。我见过用户截这个图来反馈bug说页面上出现了英文字母。这个处理起来很简单给列配置里加一个显示值的映射null统一转成空字符串或自定义文案。第五个坑编辑表格时更新指定字段。热搜词里那个vxe-table改变list中的某一项的指定字段就是我说的场景。表格里做行内编辑用户改了某一行某个字段后你需要在data里更新对应行的对应字段。如果原字段是null更新后变成字符串这个过程中如果有diff逻辑比如只提交有变化的字段null和字符串会被判断为发生了变化导致提交多余数据// 旧值 null新值 张三 if (oldValue ! newValue) { // 这里会判定为变化但你可能只关心内容是否真的变了 }2.3 渲染层防护可选链、管道函数与降级文案模板层的防护思路我用一个优先级排序能不写逻辑就不写逻辑要写逻辑就集中在格式化函数里模板里只负责展示。第一层防护是可选链和空值合并span{{ item.customerName ?? 暂无 }}/span span{{ item.userInfo?.age ?? - }}/span??只在左侧为null或undefined时取右侧值不会误伤0和空字符串。这一点比||安全得多。热搜词里有个典型的例子——uview-plus cannot read properties of null (reading matches)这个就是在uni-app项目里某个字段为null然后框架内部调用了字符串的matches方法导致崩溃。如果你在模板里就做了一层?? 的兜底根本不会走到那一步。第二层防护是表格组件的formatter统一处理// 安全的金额格式化 const formatAmount (value) { if (value null || value undefined || value ) { return -; } return Number(value).toFixed(2); };第三层防护是针对整列空白的主动发现。我的做法是在表格渲染完后用一个函数扫描每一列统计null/undefined/空值的占比如果超过阈值比如30%就在控制台打一条warn日志提示开发者检查字段契约。3. 逻辑层断裂list.map is not a function这类崩溃的完整排查链路3.1 三类高频报错map、length、深层属性访问逻辑层的null问题代码上比渲染层更直接因为你在函数里写的每一行都可能成为引爆点。我在团队里做过统计前端生产环境报错排名前三的是1. Cannot read properties of null (reading map) 2. Cannot read properties of null (reading length) 3. Cannot read properties of null (reading id) / name / status先说第一类。后端返回的列表接口前端常常直接这么写const orderList res.data.list.map(item ({ ...item }));如果res.data.list是null直接炸。很多时候后端逻辑是这样的查询订单列表列表为空时返回list: null有数据时返回数组。前端没有任何前置判断第一行就崩。第二类reading length经常出现在分页组件里const totalPages Math.ceil(res.data.total / res.data.pageSize); // total为null if (res.data.list.length 0) { // list为null this.emptyState true; }第三类是列表单项里的深层字段。比如item.userInfo.nameuserInfo为null直接崩。我把这三类报错的关系画成一个排查逻辑你们可以照着走一遍报错里提到的字段先看它在接口返回里是否存在。直接F12看Network找对应请求的Response。判断它是什么类型的nullkey存在值为null还是key根本不存在undefined。在入口日志里打印这一层数据console.log(接口返回, res.data)确认是后端问题还是前端处理问题。最小化复现用一条脏数据写个demo跑一遍报错的代码确认触发条件。3.2 防御性编程的正确姿势可选链、空值合并与类型守卫很多防御代码写得不好不是因为不懂语法而是不知道每个语法的适用边界。我把几个常用方案盘一下方案一可选链?.const name item.customer?.name;这能防止customer为null时报错但如果item本身就是nullitem.customer?.name会在item.customer前先访问item一样崩。所以可选链只能解决当前层以下的null不能解决当前层本身。方案二空值合并??const amount item.amount ?? 0;??只在左右值为null或undefined时生效。它解决的问题是给null一个默认值但它不解决item.amount这个访问路径是否安全。顺序应该是先?.后??const amount item?.amount ?? 0;方案三类型守卫const safeList (list) Array.isArray(list) ? list : []; const list safeList(res.data.list); list.map(item { ... });这个方案比?.更稳因为Array.isArray一下就把null、undefined、对象、字符串全拦截了。它还有额外的好处如果后端返回的是对象而不是数组你能第一时间发现字段契约问题而不是让代码默默用空数组继续跑。方案四编写safeGet工具函数const get (obj, path, defaultValue) { try { return path.split(.).reduce((acc, key) acc?.[key], obj) ?? defaultValue; } catch { return defaultValue; } }; // 用法 const name get(item, userInfo.name, 未知用户);这个工具函数我个人强烈建议放在项目的utils目录里所有深层属性访问都走它。它有个好处即便路径中间的某一层是null也不会抛异常直接落到默认值。这对后端返回嵌套对象结构非常实用。3.3 从报错到修复的完整排查链路一个真实的案例复盘我拿热搜词里那个uview-plus cannot read properties of null (reading matches)做一个完整复盘。这个报错在uni-app项目里非常典型。现场是这样的一个列表页用uview-plus的组件渲染数据。线上用户反馈进入页面后白屏控制台报Cannot read properties of null (reading matches)。当时的排查链路我一步步还原第一步看报错栈。报错指向的调用栈在uview-plus内部的一个方法里不是我们业务代码。但报错源头一定是我们传进去的数据有问题。第二步看传参。找到调用该组件处的代码确认传给组件的字段值。发现我们传了一个keyword字段值是接口返回的其中一条是null。组件内部可能用keyword.matches(/.../)做正则匹配null直接崩。第三步确认null来源。打开Network接口返回搜索keyword发现该字段在部分数据行里确实是null。后端反馈这个字段是可空字段懒得设置默认值。第四步修复。不能让业务代码去猜组件的内部实现最稳妥的做法是在前端入口处统一清洗const rawList res.data.list || []; const cleanedList rawList.map(item ({ ...item, keyword: item.keyword ?? // null转成空字符串 }));这样组件拿到的keyword永远是字符串正则匹配就不会崩。类似的修复思路适用于任何组件内部读字段做操作的场景——比如素材地址、富文本内容、正则规则等null都可能引发组件内部崩溃。第五步补充一层全局兜底。我在项目的uni-app请求封装里加了一个统一的normalizeList函数把常见列表字段的null自动清洗。后面新页面只要走了统一请求封装就不会再被这类问题偷袭。4. 数据传递中的null变形记深拷贝、拦截器与批量更新4.1 JSON.parse(JSON.stringify())的隐性地雷null和undefined行为完全不同前端项目里没人能逃过JSON.parse(JSON.stringify(obj))这个深拷贝土办法。但很多人不知道它对null的处理有两个截然不同的分支const obj { a: null, // 会被保留 b: undefined, // 会消失 c: 0, // 会保留 d: , // 会保留 e: () {}, // 会消失 f: new Date() // 会被转成字符串 }; JSON.stringify(obj); // 输出: {a:null,c:0,d:,f:2024-03-18T02:22:00.000Z}看到了吗null会被保留undefined会被直接丢弃。所以在深拷贝之后原本是undefined的字段会消失而原本是null的字段会原样保留。这会导致一个很难查的问题拷贝前后的对象结构不一样了。举一个具体的例子。接口返回列表其中一个字段customerName在部分行里是null部分行里有值。你为了编辑功能做了一次深拷贝const copy JSON.parse(JSON.stringify(this.orderList));然后你在copy对象里修改customerName提交时用Object.keys遍历字段。因为null字段还在更新会提交但如果某个字段原本是undefined拷贝后key直接消失你遍历时根本遍历不到它更新逻辑就会漏掉这个字段。另一个坑在structuredClone。浏览器原生支持的结构化克隆会保留更多数据类型包括Map、Set、TypedArray对于普通对象里的null行为和JSON.parse(JSON.stringify())基本一致。但注意structuredClone对函数、Symbol、DOM节点会抛异常所以也不是万能钥匙。我的建议是做深拷贝前先明确你要拷贝的数据里有没有undefined字段如果有给它们赋默认值再拷贝。要么就在拷贝后手动补齐关键字段const copy JSON.parse(JSON.stringify(this.orderList)); copy.forEach(item { item.customerName item.customerName ?? ; });4.2 响应拦截器统一兜底把列表字段null扼杀在入口前面说的都是遇到了null再处理但更狠的做法是根本不让null进入业务代码。我在axios的response拦截器里做了一层统一清洗效果立竿见影。核心思路是给响应数据加一个normalize阶段// http.js - axios实例配置 axios.interceptors.response.use( (response) { const data response.data; if (data data.code 0) { data.data normalizePayload(data.data); } return data; }, (error) { return Promise.reject(error); } );normalizePayload是一个函数它对常见的列表结构做兜底function normalizePayload(payload) { if (!payload || typeof payload ! object) return payload; const result { ...payload }; // 常见的列表外层字段list、rows、records、items [list, rows, records, items].forEach((key) { if (key in result !Array.isArray(result[key])) { result[key] Array.isArray(result[key]) ? result[key] : []; } }); return result; }这里有个关键点只处理应该为数组但实际不是数组的情况而不是把所有非数组都转成数组。因为有些字段确实可能返回对象误转成数组会让类型变得更混乱。在拦截器做了一轮清洗之后业务代码里的res.data.list.map()就不会因为list为null而崩溃了。剩下的null都集中在列表项内部字段可以在渲染组件或格式化函数里二次处理。4.3 批量更新指定字段时null引发次生灾害的实战复盘热搜词里有一个场景很贴切——四百多条数据更新一个字段这个字段会是一个动态值。我做一个复盘复盘。当时需求是这样的页面上有400多条数据用户批量操作给每条数据动态修改某个字段。后端要求只提交有变化的数据。问题来了数据里部分行该字段是null。前端做diff时把null → 新值也认为是变化。实际上用户只修改了部分行但diff把null行也带上。这会导致后端收到一大批看似被修改的数据。如果后端没有校验就直接覆盖了原来可能是null或其他值的字段如果有变更日志就会看到大量无关的更新记录。解决办法是在diff前统一归一化const patchList originalList .map((item, index) { const newValue item.editableValue ?? null; if (item.editableValue ! item.originalValue) { return { id: item.id, value: newValue }; } return null; }) .filter(Boolean);但这里又有一个细节newValue如果设置成全null后端收到的是value: null这可能是合法的业务操作用户主动清空该字段。所以diff逻辑需要区分三种状态字段本来就是null用户没动它 → 不提交。字段从非null改成null → 提交语义是清空。字段从null改成有值 → 提交语义是填充。代码要按这个语义分开写而不能用一个!一棍子打死。真正能在实际项目里落地批量更新这些边界条件必须提前设计好。5. 不同技术栈对null的脾气Vue2、Vue3、React与TypeScript5.1 Vue2响应式系统对null的特殊表现Vue2的响应式基于Object.defineProperty它对null的处理有一个很微妙的地方新增属性不是响应式的。比如你在data里初始化了data() { return { list: [] }; }请求返回后你给某个列表项动态添加了一个后端返回的字段this.list[i].isSelected null;这个isSelected不是响应式的后续你修改它视图不会更新。Vue2官方给出的方案是用this.$set。所以Vue2项目里遇到字段为null但页面没反应先排查是不是用了动态添加字段的方式。另一个Vue2的典型场景v-for循环渲染的列表项如果某个字段初始是null你在input里修改它v-model会正常工作因为该字段在data初始化时已经存在。但如果字段压根没有在初始对象里定义接口没返回用undefined初始化v-model的表现就不一样了——输入框显示空了以后再输入数据是有了可视图在第一次渲染时就是空的无碍但如果你在watch里对undefined做判断就可能踩坑。5.2 Vue3组合式API与TS联合类型null从运行时问题变成编译期问题Vue3最大的变化是TypeScript的一等公民支持。在这种技术栈下null的处理习惯和Vue2完全不一样——能用类型解决的问题别留到运行时。比如定义接口返回类型interface OrderItem { orderId: string; customerName: string | null; // 明确标注可能为null amount: number | null; userInfo?: UserInfo | null; // 可选且可能为null }有了这个类型声明你在写item.customerName.toUpperCase()时编辑器会直接标红因为customerName可能是null。这是把null问题从运行时提前到了编译期成本最低效果最好。但要注意string | null和string | undefined是两种不同类型。接口返回时字段不存在是undefined显式是null才是null。你写类型时最好跟上一步说的实际返回对齐// 如果后端开了NON_NULL导致字段直接消失类型应该写成 string | undefined // 如果后端保留 null类型应该写成 string | null如果拿不准稳妥写法是string | null | undefined把两种可能都覆盖掉。虽然丑但确实安全。Vue3的模板里可选链和空值合并都能正常用span{{ item.userInfo?.name ?? - }}/span不过要说一句模板里用?.和??只能在组合式API语法script setup下使用吗不是的Vue3的模板编译器直接支持Vue2需要看版本。Vue2.6以下不支持模板内可选链需要写在计算属性里。5.3 React的null哲学React把null当合法子节点组件内部才是真正的引爆区React对null的态度和Vue完全不同。在JSX里null是合法的子节点——渲染null就什么都不显示不会报错div{value}/div {/* value为null时渲染为空 */}所以React里字段为null通常不会导致渲染崩溃。真正的崩盘点在逻辑调用层const List ({ data }) { return ( ul {data.map(item li{item.name}/li)} {/* data为null时直接崩 */} /ul ); };React的函数组件接props后直接调.map如果父组件传了null整个组件崩溃。React的ErrorBoundary可以在一定程度上兜住渲染错误但更常见的做法还是在组件开头做一次默认值处理const List ({ data [] }) { return ( ul {data.map(item li{item?.name ?? 未命名}/li)} /ul ); };React Hook里也有个和null高度相关的坑useEffect依赖数组里如果包含null字段每次渲染时null和变成值之后的变化都会触发effect重新执行。如果effect里做了接口请求等于每次字段从null变有值都会多发请求这在表单联动场景很容易造成重复提交值得注意。5.4 TS strictNullChecks类型层面强制收敛null最后聊一下TypeScript的strictNullChecks配置。如果项目开了这个选项现在的新项目几乎默认开null和undefined就不再是所有类型的子类型你必须显式处理它们才能通过编译。这意味着什么呢意味着很多前端处理null的代码在TS项目里会变成编译期强制要求。比如function formatAmount(value: number | null) { return value.toFixed(2); // 报错对象可能为null }编译器会提示你必须先做判断function formatAmount(value: number | null) { if (value null) return -; return value.toFixed(2); }这个特性对团队协作意义很大。我在很多项目里看到没开strictNullChecks的时候新手写代码经常漏掉null判断上线后炸开了之后编译器帮你堵住大部分入口。所以如果你的项目用的是TypeScript一定把strictNullChecks打开这比任何防御性代码都管用。6. 一劳永逸的治理方案给接口数据加一道清洗流水线6.1 字段级配置用声明式规则代替散落的if判断每次写一个if判断处理null是在打地鼠。我今天把customerName修好了明天userInfo在别的地方又崩了。根治的办法是建立一个数据清洗流水线用配置驱动的方式统一处理。我的做法是设计一个FieldConfig配置表。给每个接口、每个字段配置好它的默认姿势// fieldConfig.js export const orderListConfig { list: { type: array, default: [] }, list[].customerName: { type: string, default: -- }, list[].amount: { type: number, default: 0 }, list[].status: { type: enum, default: unknown, mapping: { 0: 待支付, 1: 已支付, 2: 已取消 } }, list[].remark: { type: string, default: }, list[].createTime: { type: date, default: null }, list[].userInfo.name: { type: string, default: 未知用户 }, };然后写一个通用的normalize函数按照配置逐字段清洗// normalize.js function normalizeData(data, config) { if (Array.isArray(data)) { return data.map(item normalizeData(item, config)); } if (data typeof data object) { const result { ...data }; Object.keys(config).forEach((key) { if (key.includes([])) { // 处理数组内字段 const [arrayPath, fieldPath] key.split([]); const arr get(result, arrayPath); if (Array.isArray(arr)) { const fieldConfig { [fieldPath]: config[key] }; set(result, arrayPath, arr.map(item normalizeData(item, fieldConfig))); } } else { const value get(result, key); if (value null || value undefined) { set(result, key, config[key].default); } } }); return result; } return data; }这个方案的核心价值在于所有null处理逻辑集中在配置表里而不是散布在页面各处的if判断中。产品说备注为空时要显示暂无备注改一行配置就行不用去翻页面代码。后段说某个字段可能为null注意处理加一行配置就行不用每个页面都看一眼。6.2 列表级normalize的性能实测400条数据、20列字段的洗数据成本关于清洗流水线很多人第一反应是会不会影响性能。我实际测过。拿400条数据、每条20个字段、逐字段做null检查在普通开发机i5处理器、Chrome浏览器上跑一趟耗时大约在2到5毫秒之间。这几乎可以忽略不计。但要注意一点不要在网络请求的回调里做一些无意义的深拷贝。清洗时尽量原地修改或者用浅拷贝字段覆盖。我遇到过团队里有人为了不可变数据在normalize里JSON.parse(JSON.stringify(data))了一下400条数据硬生生变成了30毫秒。这没必要因为我们清洗的目的是修正null值不是冻结数据快照。我实际项目里的折中方案是只对进入表格和表单的数据做normalize接口原始数据保留一份。这样既有了干净数据又能回溯原始状态。6.3 特殊字段的降级展示图片、富文本、动态字段为null时怎么办清洗流水线把null统一成默认值之后还要处理一类特殊的字段——它们无法用默认值简单覆盖需要在UI层做降级设计。图片字段用户头像、商品图片如果为null直接塞一个默认图片URL或者一个占位图标const imgSrc item.avatar ?? https://your-cdn.com/default-avatar.png;富文本字段富文本内容为null页面渲染时显示一个暂无内容的空状态而不是留着整块空白。这个和remark的处理方式类似但要注意富文本组件内部的HTML解析——null经过组件后可能变成pnull/p这种奇怪结构所以必须在传参前转成空字符串。动态字段、聚合计算字段热搜词里提到group by 多个字段这类场景动态生成的计算字段比如totalCount、avgAmount如果为null常常需要避免展示时出现¥null这样的文字污染。我一般会写一个统一展示格式化函数const formatDisplay (value, { type text, prefix , suffix } {}) { if (value null || value undefined || value ) { return --; } return ${prefix}${value}${suffix}; };特殊字段的核心原则是空状态也要有设计感。一个页面里暂无数据--未填写待补充是不同的语义不要全部堆成空白或者null字符串。统一文案和样式之后产品体验会上升一大截。写到这里回头看这个问题的本质null本身不是灾难灾难在于我们总是假设数据是完美的。每次接手新项目我都习惯先打开Network把所有接口翻一遍全局搜null心里有数之后再写业务代码。你可以在自己项目里试试这个小习惯它比任何框架技巧都更早地帮你避开雷区。
1. 先定位这个null到底是从哪一层冒出来的1.1 后端产出的null数据库空值、ORM映射与聚合函数接手过中后台项目的人都懂一个规律线上95%的前端白屏事故最后都能在一堆报错里翻到一个关键词——null。而最常见的场景就是前端接收结果列表时列表里某个字段值是null页面渲染或者逻辑处理直接崩了。我先说一句可能很多人不爱听的话null不是bug是常态。只要数据库字段允许为空、只要查询结果可能没有匹配行、只要上游系统传参有缺省后端就一定会返回null。防不住也没必要防你要做的是先搞清楚这个null是哪一层冒出来的。我用一个真实例子来说明。项目里有个订单列表接口后端返回的数据结构大概是这样的{ code: 0, data: { list: [ { orderId: A10001, customerName: 张三, amount: 199.00, remark: null, createTime: 2024-03-18 10:22:00 }, { orderId: A10002, customerName: null, amount: null, remark: 加急处理, createTime: null } ] } }注意第二行数据customerName、amount、createTime全是null。这种数据是怎么来的我拆开说数据库字段本身允许NULL比如customer_name VARCHAR(50) NULL如果下单时没记录客户名查出来就是NULL。LEFT JOIN 右表无匹配订单表左连接客户表如果客户信息被删了或者关联ID对不上那么连出来的customer_name就是NULL。聚合查询的经典坑用COUNT、SUM、AVG做统计时如果没有匹配行很多数据库返回的结果不是一个数字而是NULL。有些后端同学直接用sum(...)映射到totalAmount字段前端拿到totalAmount: null是很正常的事。热搜词里那个group by 多个字段的场景多半也是这个套路——分组统计的别名字段一旦没匹配行就是null。ORM框架的默认映射Java的MyBatis、Golang的GORM当查询结果中某列没有值结构体里对应的字段默认就是零值或者nil。如果后端忘了设置默认值JSON序列化时就是null。所以当你发现列表里某个字段是null第一步不是打开编辑器写防御代码而是先问后端一句这个字段在什么业务场景下会是null是允许为空还是数据异常这两种情况的处理策略完全不同。1.2 序列化与网络传输null在JSON里是怎么保命的如果说数据库和ORM决定了null的出生那JSON序列化则决定了null的长相。这里有个巨坑同一个null在不同的后端序列化配置下到前端手里可能是完全不同的形态。我用Java生态举几个例子前端同学不一定写后端但至少要看得懂接口返回序列化方案null字段默认输出说明JacksonSpring Boot默认field: null保留字段名值为nullJackson NON_NULL配置字段直接消失JSON里根本没有这个keyGsonfield: null默认保留Fastjsonfield: null默认保留部分版本行为不一致Golangencoding/jsonfield: null指针类型为nil时输出nullGolangomitempty字段直接消失结构体标签控制这个区别对前端影响巨大。如果后端开了NON_NULL你前端写if (res.data.remark null)是永远不成立的因为remark这个key压根不存在取出来的值是undefined而不是null。很多前端新手就在这里栽跟头明明接口文档说这个字段可能为null代码里判断了 null结果走了else分支逻辑全错。所以在前端处理null之前我先给一个建议在浏览器Network面板里看接口的实际返回JSON而不是只看接口文档。你要先确认三件事这个字段是field: null还是 key 直接消失这个字段的值是所有行都null还是部分行为null列表外层字段比如data.list本身有没有可能也是null第三点极其重要。太多人只盯着列表里的字段忽略了list本身也可能为null。后端返回list: null和返回list: []是两种完全不同的心境——前者会让你的res.data.list.map(...)直接抛异常后者则安静如鸡。1.3 拿到第一手数据先别急着修先判断null的性质排查null问题时我养成了一个固定习惯把接口返回的JSON扔到编辑器的格式化工具里全局搜索null然后逐个判断每个null的性质。这一步对后面写代码帮助极大。判断方法也很简单对着字段问三个问题这个字段在业务上允许为空吗比如订单的备注字段空是常态前端显示空白或暂无备注就好不需要任何特殊逻辑。这个字段为空会破坏后续计算吗比如金额、数量、日期如果后续要做排序、加总、格式化null就会引发连锁反应。这个字段为空会影响页面主流程吗比如用户头像、商品主图图片类字段是null前端如果直接丢给img的src会出现裂图或者转圈需要降级成默认图。我自己在做项目梳理时会给每个字段打一个标签safe-null、danger-null、critical-null。safe-null是备注、描述这类纯展示文本danger-null是参与计算、排序、拼接的字段critical-null是一旦为null整个页面或模块就无法工作的字段。这样定位问题、写防御代码时心里就有了一张地图而不是每次都在代码里临时打补丁。2. 模板与表格组件null在渲染层的真实破坏力2.1 插值、v-model与v-for哪些情况会崩哪些只会留白先说结论在Vue模板里直接插值一个null字段页面不会崩它会被渲染成空字符串。比如span{{ item.customerName }}/span当customerName为null时页面显示空白浏览器不会报警。真正会报错的是下面这些场景span{{ item.customerName.toUpperCase() }}/span span{{ item.userInfo.age }}/span span :titleitem.remark.substring(0, 10){{ item.remark }}/span这三个例子分别代表了三种崩溃模式直接调用方法null没有toUpperCase方法运行时抛Cannot read properties of null (reading toUpperCase)。深层属性访问item.userInfo为null再去读.age报Cannot read properties of null (reading age)。方法链访问item.remark.substring(0, 10)remark为null直接崩。有意思的是如果item.userInfo本身是null模板里的{{ item.userInfo.age }}不会白屏而是渲染成空。因为Vue的模板编译器对深层属性访问做了容错处理读不到值就返回undefined最终显示为空。但如果你在计算属性、watcher或methods里写同样的代码那就不客气了直接抛异常。再说v-for。v-foritem in list如果list是nullVue2和Vue3都不会报错渲染结果为空。但是v-for里的:keyitem.id如果id是null虽然不报错但key全是null会导致列表复用逻辑错乱可能出现勾选状态错位、动画不更新、编辑弹窗内容串行等问题。v-model的场景也值得注意。如果绑定值是nullinput v-modelitem.customerName会显示空输入框用户一输入字段就从null变成字符串。这个行为看似正常但在表单回显场景下有个隐患你无法区分用户清空了输入框和字段本来就是null提交时可能把原本的非空字段改成了空字符串。所以表单类需求我一般会跟产品确认字段为空时提交null还是空串两者在后端存储和查询时的语义完全不同。2.2 表格组件的连环坑el-table、vxe-table整列空白与formatter崩溃如果说模板插值是毛毛雨那表格组件就是雷暴区。我在实际项目里用el-table和vxe-table都踩过坑列出最典型的几种现场第一个坑整列空白。表格某列的字段在所有行里都是null时列会直接显示成空白。用户看到的效果是这一列消失了一样但表头还在。产品会问为什么这一列全是空的排查代码发现是后端没返回数据或者字段名对不上。这个问题不报错却非常致命——它会让用户以为是页面bug但其实是你和后端的字段契约没对齐。第二个坑formatter函数里null直接崩。很多人会在表格列配置里写formatter// 伪代码金额格式化 formatter: (row) { return row.amount.toFixed(2); // amount为null时直接崩溃 }null没有toFixed、substring、replace、split这些方法formatter一执行就抛异常表格要么整页白屏要么这一列全部渲染失败。vxe-table在某些版本里还会把这个异常吞掉表现为表格渲染到一半卡住。第三个坑排序时null的位置。给amount字段加排序如果某行的amount: null默认排序行为是null被排到最前面升序或者最后面降序取决于组件实现。有时候产品要求null永远排在最后这时候你需要自定义排序函数const compareAmount (a, b) { if (a.amount null) return 1; // null永远排到最后 if (b.amount null) return -1; return a.amount - b.amount; };第四个坑tooltip显示null字符串。表格列开了show-overflow-tooltip当字段值是null时鼠标悬停显示的工具提示是null这个字符串而不是空白。我见过用户截这个图来反馈bug说页面上出现了英文字母。这个处理起来很简单给列配置里加一个显示值的映射null统一转成空字符串或自定义文案。第五个坑编辑表格时更新指定字段。热搜词里那个vxe-table改变list中的某一项的指定字段就是我说的场景。表格里做行内编辑用户改了某一行某个字段后你需要在data里更新对应行的对应字段。如果原字段是null更新后变成字符串这个过程中如果有diff逻辑比如只提交有变化的字段null和字符串会被判断为发生了变化导致提交多余数据// 旧值 null新值 张三 if (oldValue ! newValue) { // 这里会判定为变化但你可能只关心内容是否真的变了 }2.3 渲染层防护可选链、管道函数与降级文案模板层的防护思路我用一个优先级排序能不写逻辑就不写逻辑要写逻辑就集中在格式化函数里模板里只负责展示。第一层防护是可选链和空值合并span{{ item.customerName ?? 暂无 }}/span span{{ item.userInfo?.age ?? - }}/span??只在左侧为null或undefined时取右侧值不会误伤0和空字符串。这一点比||安全得多。热搜词里有个典型的例子——uview-plus cannot read properties of null (reading matches)这个就是在uni-app项目里某个字段为null然后框架内部调用了字符串的matches方法导致崩溃。如果你在模板里就做了一层?? 的兜底根本不会走到那一步。第二层防护是表格组件的formatter统一处理// 安全的金额格式化 const formatAmount (value) { if (value null || value undefined || value ) { return -; } return Number(value).toFixed(2); };第三层防护是针对整列空白的主动发现。我的做法是在表格渲染完后用一个函数扫描每一列统计null/undefined/空值的占比如果超过阈值比如30%就在控制台打一条warn日志提示开发者检查字段契约。3. 逻辑层断裂list.map is not a function这类崩溃的完整排查链路3.1 三类高频报错map、length、深层属性访问逻辑层的null问题代码上比渲染层更直接因为你在函数里写的每一行都可能成为引爆点。我在团队里做过统计前端生产环境报错排名前三的是1. Cannot read properties of null (reading map) 2. Cannot read properties of null (reading length) 3. Cannot read properties of null (reading id) / name / status先说第一类。后端返回的列表接口前端常常直接这么写const orderList res.data.list.map(item ({ ...item }));如果res.data.list是null直接炸。很多时候后端逻辑是这样的查询订单列表列表为空时返回list: null有数据时返回数组。前端没有任何前置判断第一行就崩。第二类reading length经常出现在分页组件里const totalPages Math.ceil(res.data.total / res.data.pageSize); // total为null if (res.data.list.length 0) { // list为null this.emptyState true; }第三类是列表单项里的深层字段。比如item.userInfo.nameuserInfo为null直接崩。我把这三类报错的关系画成一个排查逻辑你们可以照着走一遍报错里提到的字段先看它在接口返回里是否存在。直接F12看Network找对应请求的Response。判断它是什么类型的nullkey存在值为null还是key根本不存在undefined。在入口日志里打印这一层数据console.log(接口返回, res.data)确认是后端问题还是前端处理问题。最小化复现用一条脏数据写个demo跑一遍报错的代码确认触发条件。3.2 防御性编程的正确姿势可选链、空值合并与类型守卫很多防御代码写得不好不是因为不懂语法而是不知道每个语法的适用边界。我把几个常用方案盘一下方案一可选链?.const name item.customer?.name;这能防止customer为null时报错但如果item本身就是nullitem.customer?.name会在item.customer前先访问item一样崩。所以可选链只能解决当前层以下的null不能解决当前层本身。方案二空值合并??const amount item.amount ?? 0;??只在左右值为null或undefined时生效。它解决的问题是给null一个默认值但它不解决item.amount这个访问路径是否安全。顺序应该是先?.后??const amount item?.amount ?? 0;方案三类型守卫const safeList (list) Array.isArray(list) ? list : []; const list safeList(res.data.list); list.map(item { ... });这个方案比?.更稳因为Array.isArray一下就把null、undefined、对象、字符串全拦截了。它还有额外的好处如果后端返回的是对象而不是数组你能第一时间发现字段契约问题而不是让代码默默用空数组继续跑。方案四编写safeGet工具函数const get (obj, path, defaultValue) { try { return path.split(.).reduce((acc, key) acc?.[key], obj) ?? defaultValue; } catch { return defaultValue; } }; // 用法 const name get(item, userInfo.name, 未知用户);这个工具函数我个人强烈建议放在项目的utils目录里所有深层属性访问都走它。它有个好处即便路径中间的某一层是null也不会抛异常直接落到默认值。这对后端返回嵌套对象结构非常实用。3.3 从报错到修复的完整排查链路一个真实的案例复盘我拿热搜词里那个uview-plus cannot read properties of null (reading matches)做一个完整复盘。这个报错在uni-app项目里非常典型。现场是这样的一个列表页用uview-plus的组件渲染数据。线上用户反馈进入页面后白屏控制台报Cannot read properties of null (reading matches)。当时的排查链路我一步步还原第一步看报错栈。报错指向的调用栈在uview-plus内部的一个方法里不是我们业务代码。但报错源头一定是我们传进去的数据有问题。第二步看传参。找到调用该组件处的代码确认传给组件的字段值。发现我们传了一个keyword字段值是接口返回的其中一条是null。组件内部可能用keyword.matches(/.../)做正则匹配null直接崩。第三步确认null来源。打开Network接口返回搜索keyword发现该字段在部分数据行里确实是null。后端反馈这个字段是可空字段懒得设置默认值。第四步修复。不能让业务代码去猜组件的内部实现最稳妥的做法是在前端入口处统一清洗const rawList res.data.list || []; const cleanedList rawList.map(item ({ ...item, keyword: item.keyword ?? // null转成空字符串 }));这样组件拿到的keyword永远是字符串正则匹配就不会崩。类似的修复思路适用于任何组件内部读字段做操作的场景——比如素材地址、富文本内容、正则规则等null都可能引发组件内部崩溃。第五步补充一层全局兜底。我在项目的uni-app请求封装里加了一个统一的normalizeList函数把常见列表字段的null自动清洗。后面新页面只要走了统一请求封装就不会再被这类问题偷袭。4. 数据传递中的null变形记深拷贝、拦截器与批量更新4.1 JSON.parse(JSON.stringify())的隐性地雷null和undefined行为完全不同前端项目里没人能逃过JSON.parse(JSON.stringify(obj))这个深拷贝土办法。但很多人不知道它对null的处理有两个截然不同的分支const obj { a: null, // 会被保留 b: undefined, // 会消失 c: 0, // 会保留 d: , // 会保留 e: () {}, // 会消失 f: new Date() // 会被转成字符串 }; JSON.stringify(obj); // 输出: {a:null,c:0,d:,f:2024-03-18T02:22:00.000Z}看到了吗null会被保留undefined会被直接丢弃。所以在深拷贝之后原本是undefined的字段会消失而原本是null的字段会原样保留。这会导致一个很难查的问题拷贝前后的对象结构不一样了。举一个具体的例子。接口返回列表其中一个字段customerName在部分行里是null部分行里有值。你为了编辑功能做了一次深拷贝const copy JSON.parse(JSON.stringify(this.orderList));然后你在copy对象里修改customerName提交时用Object.keys遍历字段。因为null字段还在更新会提交但如果某个字段原本是undefined拷贝后key直接消失你遍历时根本遍历不到它更新逻辑就会漏掉这个字段。另一个坑在structuredClone。浏览器原生支持的结构化克隆会保留更多数据类型包括Map、Set、TypedArray对于普通对象里的null行为和JSON.parse(JSON.stringify())基本一致。但注意structuredClone对函数、Symbol、DOM节点会抛异常所以也不是万能钥匙。我的建议是做深拷贝前先明确你要拷贝的数据里有没有undefined字段如果有给它们赋默认值再拷贝。要么就在拷贝后手动补齐关键字段const copy JSON.parse(JSON.stringify(this.orderList)); copy.forEach(item { item.customerName item.customerName ?? ; });4.2 响应拦截器统一兜底把列表字段null扼杀在入口前面说的都是遇到了null再处理但更狠的做法是根本不让null进入业务代码。我在axios的response拦截器里做了一层统一清洗效果立竿见影。核心思路是给响应数据加一个normalize阶段// http.js - axios实例配置 axios.interceptors.response.use( (response) { const data response.data; if (data data.code 0) { data.data normalizePayload(data.data); } return data; }, (error) { return Promise.reject(error); } );normalizePayload是一个函数它对常见的列表结构做兜底function normalizePayload(payload) { if (!payload || typeof payload ! object) return payload; const result { ...payload }; // 常见的列表外层字段list、rows、records、items [list, rows, records, items].forEach((key) { if (key in result !Array.isArray(result[key])) { result[key] Array.isArray(result[key]) ? result[key] : []; } }); return result; }这里有个关键点只处理应该为数组但实际不是数组的情况而不是把所有非数组都转成数组。因为有些字段确实可能返回对象误转成数组会让类型变得更混乱。在拦截器做了一轮清洗之后业务代码里的res.data.list.map()就不会因为list为null而崩溃了。剩下的null都集中在列表项内部字段可以在渲染组件或格式化函数里二次处理。4.3 批量更新指定字段时null引发次生灾害的实战复盘热搜词里有一个场景很贴切——四百多条数据更新一个字段这个字段会是一个动态值。我做一个复盘复盘。当时需求是这样的页面上有400多条数据用户批量操作给每条数据动态修改某个字段。后端要求只提交有变化的数据。问题来了数据里部分行该字段是null。前端做diff时把null → 新值也认为是变化。实际上用户只修改了部分行但diff把null行也带上。这会导致后端收到一大批看似被修改的数据。如果后端没有校验就直接覆盖了原来可能是null或其他值的字段如果有变更日志就会看到大量无关的更新记录。解决办法是在diff前统一归一化const patchList originalList .map((item, index) { const newValue item.editableValue ?? null; if (item.editableValue ! item.originalValue) { return { id: item.id, value: newValue }; } return null; }) .filter(Boolean);但这里又有一个细节newValue如果设置成全null后端收到的是value: null这可能是合法的业务操作用户主动清空该字段。所以diff逻辑需要区分三种状态字段本来就是null用户没动它 → 不提交。字段从非null改成null → 提交语义是清空。字段从null改成有值 → 提交语义是填充。代码要按这个语义分开写而不能用一个!一棍子打死。真正能在实际项目里落地批量更新这些边界条件必须提前设计好。5. 不同技术栈对null的脾气Vue2、Vue3、React与TypeScript5.1 Vue2响应式系统对null的特殊表现Vue2的响应式基于Object.defineProperty它对null的处理有一个很微妙的地方新增属性不是响应式的。比如你在data里初始化了data() { return { list: [] }; }请求返回后你给某个列表项动态添加了一个后端返回的字段this.list[i].isSelected null;这个isSelected不是响应式的后续你修改它视图不会更新。Vue2官方给出的方案是用this.$set。所以Vue2项目里遇到字段为null但页面没反应先排查是不是用了动态添加字段的方式。另一个Vue2的典型场景v-for循环渲染的列表项如果某个字段初始是null你在input里修改它v-model会正常工作因为该字段在data初始化时已经存在。但如果字段压根没有在初始对象里定义接口没返回用undefined初始化v-model的表现就不一样了——输入框显示空了以后再输入数据是有了可视图在第一次渲染时就是空的无碍但如果你在watch里对undefined做判断就可能踩坑。5.2 Vue3组合式API与TS联合类型null从运行时问题变成编译期问题Vue3最大的变化是TypeScript的一等公民支持。在这种技术栈下null的处理习惯和Vue2完全不一样——能用类型解决的问题别留到运行时。比如定义接口返回类型interface OrderItem { orderId: string; customerName: string | null; // 明确标注可能为null amount: number | null; userInfo?: UserInfo | null; // 可选且可能为null }有了这个类型声明你在写item.customerName.toUpperCase()时编辑器会直接标红因为customerName可能是null。这是把null问题从运行时提前到了编译期成本最低效果最好。但要注意string | null和string | undefined是两种不同类型。接口返回时字段不存在是undefined显式是null才是null。你写类型时最好跟上一步说的实际返回对齐// 如果后端开了NON_NULL导致字段直接消失类型应该写成 string | undefined // 如果后端保留 null类型应该写成 string | null如果拿不准稳妥写法是string | null | undefined把两种可能都覆盖掉。虽然丑但确实安全。Vue3的模板里可选链和空值合并都能正常用span{{ item.userInfo?.name ?? - }}/span不过要说一句模板里用?.和??只能在组合式API语法script setup下使用吗不是的Vue3的模板编译器直接支持Vue2需要看版本。Vue2.6以下不支持模板内可选链需要写在计算属性里。5.3 React的null哲学React把null当合法子节点组件内部才是真正的引爆区React对null的态度和Vue完全不同。在JSX里null是合法的子节点——渲染null就什么都不显示不会报错div{value}/div {/* value为null时渲染为空 */}所以React里字段为null通常不会导致渲染崩溃。真正的崩盘点在逻辑调用层const List ({ data }) { return ( ul {data.map(item li{item.name}/li)} {/* data为null时直接崩 */} /ul ); };React的函数组件接props后直接调.map如果父组件传了null整个组件崩溃。React的ErrorBoundary可以在一定程度上兜住渲染错误但更常见的做法还是在组件开头做一次默认值处理const List ({ data [] }) { return ( ul {data.map(item li{item?.name ?? 未命名}/li)} /ul ); };React Hook里也有个和null高度相关的坑useEffect依赖数组里如果包含null字段每次渲染时null和变成值之后的变化都会触发effect重新执行。如果effect里做了接口请求等于每次字段从null变有值都会多发请求这在表单联动场景很容易造成重复提交值得注意。5.4 TS strictNullChecks类型层面强制收敛null最后聊一下TypeScript的strictNullChecks配置。如果项目开了这个选项现在的新项目几乎默认开null和undefined就不再是所有类型的子类型你必须显式处理它们才能通过编译。这意味着什么呢意味着很多前端处理null的代码在TS项目里会变成编译期强制要求。比如function formatAmount(value: number | null) { return value.toFixed(2); // 报错对象可能为null }编译器会提示你必须先做判断function formatAmount(value: number | null) { if (value null) return -; return value.toFixed(2); }这个特性对团队协作意义很大。我在很多项目里看到没开strictNullChecks的时候新手写代码经常漏掉null判断上线后炸开了之后编译器帮你堵住大部分入口。所以如果你的项目用的是TypeScript一定把strictNullChecks打开这比任何防御性代码都管用。6. 一劳永逸的治理方案给接口数据加一道清洗流水线6.1 字段级配置用声明式规则代替散落的if判断每次写一个if判断处理null是在打地鼠。我今天把customerName修好了明天userInfo在别的地方又崩了。根治的办法是建立一个数据清洗流水线用配置驱动的方式统一处理。我的做法是设计一个FieldConfig配置表。给每个接口、每个字段配置好它的默认姿势// fieldConfig.js export const orderListConfig { list: { type: array, default: [] }, list[].customerName: { type: string, default: -- }, list[].amount: { type: number, default: 0 }, list[].status: { type: enum, default: unknown, mapping: { 0: 待支付, 1: 已支付, 2: 已取消 } }, list[].remark: { type: string, default: }, list[].createTime: { type: date, default: null }, list[].userInfo.name: { type: string, default: 未知用户 }, };然后写一个通用的normalize函数按照配置逐字段清洗// normalize.js function normalizeData(data, config) { if (Array.isArray(data)) { return data.map(item normalizeData(item, config)); } if (data typeof data object) { const result { ...data }; Object.keys(config).forEach((key) { if (key.includes([])) { // 处理数组内字段 const [arrayPath, fieldPath] key.split([]); const arr get(result, arrayPath); if (Array.isArray(arr)) { const fieldConfig { [fieldPath]: config[key] }; set(result, arrayPath, arr.map(item normalizeData(item, fieldConfig))); } } else { const value get(result, key); if (value null || value undefined) { set(result, key, config[key].default); } } }); return result; } return data; }这个方案的核心价值在于所有null处理逻辑集中在配置表里而不是散布在页面各处的if判断中。产品说备注为空时要显示暂无备注改一行配置就行不用去翻页面代码。后段说某个字段可能为null注意处理加一行配置就行不用每个页面都看一眼。6.2 列表级normalize的性能实测400条数据、20列字段的洗数据成本关于清洗流水线很多人第一反应是会不会影响性能。我实际测过。拿400条数据、每条20个字段、逐字段做null检查在普通开发机i5处理器、Chrome浏览器上跑一趟耗时大约在2到5毫秒之间。这几乎可以忽略不计。但要注意一点不要在网络请求的回调里做一些无意义的深拷贝。清洗时尽量原地修改或者用浅拷贝字段覆盖。我遇到过团队里有人为了不可变数据在normalize里JSON.parse(JSON.stringify(data))了一下400条数据硬生生变成了30毫秒。这没必要因为我们清洗的目的是修正null值不是冻结数据快照。我实际项目里的折中方案是只对进入表格和表单的数据做normalize接口原始数据保留一份。这样既有了干净数据又能回溯原始状态。6.3 特殊字段的降级展示图片、富文本、动态字段为null时怎么办清洗流水线把null统一成默认值之后还要处理一类特殊的字段——它们无法用默认值简单覆盖需要在UI层做降级设计。图片字段用户头像、商品图片如果为null直接塞一个默认图片URL或者一个占位图标const imgSrc item.avatar ?? https://your-cdn.com/default-avatar.png;富文本字段富文本内容为null页面渲染时显示一个暂无内容的空状态而不是留着整块空白。这个和remark的处理方式类似但要注意富文本组件内部的HTML解析——null经过组件后可能变成pnull/p这种奇怪结构所以必须在传参前转成空字符串。动态字段、聚合计算字段热搜词里提到group by 多个字段这类场景动态生成的计算字段比如totalCount、avgAmount如果为null常常需要避免展示时出现¥null这样的文字污染。我一般会写一个统一展示格式化函数const formatDisplay (value, { type text, prefix , suffix } {}) { if (value null || value undefined || value ) { return --; } return ${prefix}${value}${suffix}; };特殊字段的核心原则是空状态也要有设计感。一个页面里暂无数据--未填写待补充是不同的语义不要全部堆成空白或者null字符串。统一文案和样式之后产品体验会上升一大截。写到这里回头看这个问题的本质null本身不是灾难灾难在于我们总是假设数据是完美的。每次接手新项目我都习惯先打开Network把所有接口翻一遍全局搜null心里有数之后再写业务代码。你可以在自己项目里试试这个小习惯它比任何框架技巧都更早地帮你避开雷区。
