- 博客(24)
- 资源 (1)
- 收藏
- 关注
原创 (六)el-cascader 的展示值为什么不能直接 join:emitPath、路径还原与多选去重
el-cascader 的 model 值有四种形态(单选/多选 × 路径/叶子),join('/') 仅能处理路径型,无法还原完整 label。正确做法是:一次 DFS 建立 value 到 label 路径的映射索引,再按值反查祖先路径,多选时去重合并。避免递归查找、修改数据或循环引用,确保展示准确且高效。
2026-11-01 11:36:51
92
原创 (五)JSON.stringify 直接展示对象会报错:详情页结构化字段的安全序列化
JSON.stringify 仅适用于纯 JSON 数据,直接用于展示对象易因循环引用、BigInt、Map/Set、Date 等导致异常或字段丢失。详情页应先通过显式“可序列化投影”处理对象,将复杂类型转换为普通结构,再调用 stringify,确保安全、完整且格式可控的展示。避免依赖 replacer 或第三方库,优先采用清晰可维护的预处理逻辑。
2026-11-01 11:34:49
91
原创 (四)从插槽 VNode 反推表单展示值:组件识别与选项收集
在 Vue 3 中,包装组件无法直接获取子组件 v-model 的显示值。解决方案是通过解析默认插槽的 VNode 树,识别组件类型(如 el-select),从其 options、data 或插槽中的 el-option 等结构中提取选项,再根据 value 匹配对应 label;若未命中,则回退原始值。关键步骤包括:展开 Fragment、递归遍历子节点、基于组件名匹配可处理类型,并统一处理不同组件的选项来源。
2026-11-01 11:26:32
109
原创 (三)rules: [] 为什么拦不住 Element Plus 的表单级校验
ElFormItem 校验规则来自自身 rules 与表单级 rules[prop] 的合并,空数组仅清空前者,无法跳过校验。真正跳过需让字段不注册——即不传 prop。否则即使 :rules="[]",表单级规则仍会生效。正确做法是动态控制 prop 为 undefined,使字段不注册,从而在展示态跳过校验。
2026-10-31 18:49:12
310
原创 (二)Vue 3 的 attrs 不是响应式:el-form 扩展属性同步的三种方案
attrs 非响应式,导致 computed 读取其属性无法更新。因 attrs 为普通对象,不参与依赖收集,即使 DOM 属性变化也不会触发视图更新。解决方案:将属性改为 prop、使用 provide/inject 维护响应式状态,或用 MutationObserver 监听属性变化。推荐优先使用 prop 或 provide/inject,避免依赖 DOM 变化。
2026-10-31 18:40:29
458
原创 (一)为什么表单需要第三种状态:disabled、readonly 与纯文本展示
disabled与readonly控制的是“能否编辑”,而纯文本展示解决的是“是否渲染控件”,二者不在同一层级。前者保留控件形态,后者直接呈现内容,视觉、布局、格式化和可访问性均不同。仅用readonly无法实现真正的详情页效果,反而带来误判、布局错乱与格式缺失。应通过“一套模板+状态切换”实现统一管理,以纯文本展示替代控件渲染,提升一致性与体验。
2026-10-31 18:37:00
279
原创 每个节点 41 字节:把一棵百万节点树拆进 14 个 typed array
本文剖析WASM中树结构的内存占用,揭示紧凑存储的真实收益:100万节点下,数值字段压缩至41字节/节点,但字符串payload高达254字节/节点,主导内存消耗。紧凑存储核心优势在于将树关系转为索引(如parent、subtreeEnd),实现叶节点勾选性能提升167倍,而非单纯替换对象为数组。镜像层(17B)与派生层(24B)共同构成41B布局,而字符串与对象头仍无法压缩。结论:紧凑存储的收益来自“索引化”而非“数组化”。
2026-10-30 02:33:24
752
原创 100 万节点里搜 3 个字:倒排桶、5000 条截断与祖先补全
在百万节点树中搜索,瓶颈不在匹配,而在结果处理。实测显示,字符串匹配仅耗几毫秒,而“补祖先”环节占500ms,主因是命中数×平均深度。通过候选索引可将扫描范围缩小,截断机制控制结果规模(最多5000条),二者协同优化性能。关键结论:候选桶优化扫描范围,截断控制结果规模,祖先补全成本由命中数与深度决定,三者不可替代。
2026-10-29 09:37:54
327
原创 前端也需要事务:Vue Router 乐观更新、回滚与“过期事务”
本文提出“四段式事务”模式,解决前端异步操作中UI先变、结果后到导致的状态不一致问题。通过apply(快照)、navigate(异步操作)、commit(成功副作用)、rollback(失败回滚)四阶段,实现原子性与可回滚性。重点应对Vue Router导航失败不抛异常、重复导航误判、并发事务过期等陷阱,强调失败判定需结合业务意图,确保状态安全。
2026-10-29 02:31:44
511
原创 iframe 标签页不是塞个 `<iframe>` 就完事:加载态、超时、刷新与 postMessage 安全
本文探讨了基于 iframe 实现多标签页的工程化挑战,指出虽有浏览器天然隔离优势,但生产环境面临四大核心问题:全量加载、白屏无反馈、刷新语义模糊及 postMessage 安全隐患。通过懒加载(about:blank 预占位)、四态状态机(idle/loading/loaded/timeout)与精准响应式依赖优化,实现按需加载与超时控制。结合 v-show 保活上下文、覆盖层提示加载/错误状态,最终在内存与隔离间达成平衡,构建稳定可维护的 iframe 标签页系统。
2026-10-29 02:31:22
426
原创 keep-alive 缓存驱逐的时序陷阱:为什么不能路由一变就 delete
本文探讨多标签页工程化中缓存页销毁的时机问题,指出提前驱逐缓存会导致导航守卫拒绝后页面白屏且不可恢复。通过三种删除策略区分确定性:标记(可撤销)、批量执行(不可逆)、立即驱逐(仅用于确定场景)。核心结论是:在路由未确认前,应仅标记待删,避免在 watcher 中同步删除缓存。修复方案将 evictPageCache 改为 markCacheForEviction,并依赖 onActivated 或下一拍统一清理,确保行为与导航结果一致,彻底解决“取消后白屏”等致命 bug。
2026-10-28 09:18:52
299
原创 keep-alive 页面怎么“真刷新”?别改外层 key——一个 refreshVersion 的完整实现
在多标签页工程化中,刷新页面时若直接修改 key 会导致 keep-alive 缓存条目不断累积,引发性能问题。根本原因在于 key 变更被视作新组件,旧实例未被销毁。正确做法是固定外层 key(仅切换标签时变更),将刷新逻辑下沉至缓存组件内部,通过内层 PageShell 组件的 key 变化触发重建,实现“真刷新”而不破坏缓存机制。该方案保持缓存数量稳定,支持单/多根节点,已在 vue-stack-tabs 中验证。
2026-10-28 09:17:46
408
原创 Vue keep-alive 切标签后滚动位置回顶?因为 onDeactivated 里读到的 scrollTop 是 0
在 Vue 多标签页工程化中,onDeactivated 保存滚动位置失效的根本原因是:DOM 在钩子执行前已被移出文档,导致 scrollTop 恒为 0。正确做法是在滚动时实时记录位置,而非依赖停用阶段读取。通过在滚动事件中持续更新缓存,并在 onDeactivated 仅作兜底恢复,可确保切回时精准还原滚动位置。
2026-10-27 16:35:42
234
原创 MPTT树复选框的半选状态:从递归到计数器,再到区间覆盖
一棵百万节点树的勾选状态管理,从递归扫描演进至三组计数器与区间覆盖。第一代递归实现复杂度高达O(N²),第二代通过增量计数将根节点操作优化至O(N),第三代引入懒加载区间覆盖,实现O(1)更新与按需物化,仅在“仅显示顶层选中”场景启用。核心思想:半选状态应“维护”而非“计算”,避免重复遍历。实测表明,三代方案性能差异显著,最终选择性启用第三层以平衡资源与体验。
2026-10-24 08:55:36
757
原创 MPTT 不是万能编号:一棵百万节点树的增删改与批量事务
本文剖析MPTT树在大规模数据写操作中的性能瓶颈,揭示appendChild等操作在事务内外的复杂度差异:顶层追加事务内可达O(1),中间插入因全局编号平移必为O(N)。通过探针复现发现,顶层追加存在1格偏移缺陷,源于边界计算错误,暴露了MPTT对边界不变量的严格依赖。批量操作将100次操作从675ms降至6ms,核心在于避免频繁触发派生状态重建。结论:“写”的性能不只取决于结构,更取决于同步策略与边界维护的严谨性。
2026-10-23 00:24:00
504
原创 VUE3多标签组件的状态归属:从模块级单例到 provide/inject
本文揭示了Vue组件库中状态管理的深层问题:将模块级单例状态误当作应用级生命周期使用,导致SSR用户数据错乱、微前端标签互扰、测试污染等现象。通过重构,将状态从全局模块迁移至App级工厂函数,按“进程-应用-实例”三层生命周期明确归属,实现真正隔离。核心思想是:状态的主人应是其生命周期的持有者,而非代码位置。改造后,状态随App创建与销毁,彻底解决跨环境污染问题。
2026-10-22 10:26:36
338
原创 Vue3 多标签页别再只用 keep-alive:同一路由多开、每个标签独立前进后退的设计与实现
本文提出一种基于 Vue Router 的页面级缓存方案,通过 UUID 为每个页面实例生成唯一缓存身份,结合 Stack<Page> 实现标签内独立导航栈,利用 URL 中的 __tab 参数保障刷新与分享后状态恢复。相比传统 keep-alive 组件级缓存,该方案支持同路由多开、独立状态与前进/后退行为,兼顾性能与可用性,适用于 admin 系统复杂标签场景。
2026-10-21 00:48:12
298
原创 一次 SM9 握手 19.6ms:密钥交换、S_A/S_B 与 KEM + SM4-GCM
本文剖析SM9密钥交换协议核心机制:基于同一KGC的4步3消息交互,通过双线性对恒等式实现共享密钥计算。重点解析S_A/S_B的身份绑定与防重放设计,揭示KEM仅65字节封装的原理及安全性边界。实测显示完整交换仅需19.6ms,混合加密10KB仅3.21ms,验证了其在Web端的高效可行性。
2026-10-20 09:58:28
332
原创 WASM 不是银弹:一棵百万节点 Vue 树的边界账本与虚拟滚动动画
将树算法迁移至 WebAssembly 后,性能瓶颈并非算法本身,而在于跨边界调用、序列化开销与线性内存管理。通过 MPTT 编号实现子树区间化,结合紧凑数组布局与虚拟滚动,显著提升可扩展性。实测显示,10万节点建树耗时432ms,主要消耗在数据输入与内存分配。尽管 WASM 提升计算效率,但频繁的 JS/WASM 边界调用、消息克隆及内存不释放成为关键成本。最终,通过组合 Worker、局部动画与增量更新,实现220ms流畅展开动画,证明性能优化需系统性权衡——真正的加速来自架构设计,而非语言替换。
2026-10-20 00:54:01
383
原创 SM2 从 252 µs 到 24 µs:固定公钥、comb 表与签名点池
本文聚焦SM2签名性能优化,通过四步关键改进:计算层采用comb表将k·G倍点从255次降至51次;门面层缓存公钥避免重复派生;加密层预计算固定公钥下的k·P;调用层将k·G移出关键路径,构建签名点池。最终64字节签名延迟从252µs降至24µs(提速10.5×),同一代码在M4芯片上更达26×。核心瓶颈为固定基点标量乘(约89µs),其余开销来自随机数生成、编解码与内存分配。优化本质是“搬移成本”而非“消除成本”,且性能提升与吞吐量无直接关联。
2026-10-19 10:02:07
452
原创 从一条切线到 384 字节的 GT:拆开 SM9 的 R-ate pairing
本文剖析SM9中R-ate配对的性能瓶颈,拆解其核心计算流程:65轮Miller loop与final exponentiation各占约46.8%和45.0%耗时,二者几乎平分秋色。基于BN曲线与1-2-4-12扩域结构,实现采用Montgomery表示与原地乘法优化,显著提升模运算效率。通过分析二进制位分布(15个1)与稀疏线性函数特性,揭示了配对计算中平方、点加、线函数等操作的分布规律,指出仅优化单一阶段最多提升2倍,强调系统级优化的重要性。
2026-10-19 09:51:24
362
原创 为什么网页端几乎看不到 SM9?我用 WebAssembly 把验签做到 8ms
SM9作为国密中独特的标识密码算法,实现“ID即公钥”,无需证书链,适合互联网应用。但其在网页端稀缺,主因在于双线性对(pairing)运算极重、前端生态空白、实现门槛高且信任模型与浏览器不匹配。本文介绍基于AssemblyScript+WebAssembly的sm-crypto-wasm项目,通过基域Montgomery优化、扩域零堆分配、R-ate pairing加速等技术,将SM9验签性能提升至8ms,完整实现签名、加密、密钥交换等能力,包体积仅77KB,为前端部署SM9提供可行方案。
2026-10-18 19:19:34
397
原创 国密算法跑进 WebAssembly:实测 SM2 验签快 7 倍、SM4-GCM 快 11 倍
本文介绍如何用AssemblyScript + WebAssembly解决前端国密算法性能瓶颈。针对浏览器不支持SM2/SM3/SM4等问题,作者开发sm-crypto-wasm库,将核心算法编译为WASM,实现跨Node、浏览器、小程序的统一调用。通过标量交错优化SM4、HMAC下沉等手段,性能提升3-11倍,包体积按需加载,工程上兼容性强。强调语言选择与实际场景匹配,避免“自我感动”的优化,适合前端团队维护的高安全、高性能密码库需求。
2026-10-18 19:08:50
362
原创 FreeBSD新的JAIL管理工具QJAIL
一般而言,使用FreeBSD的大家都知道,jail是FreeBSD的重要组成部分,而要方便的使用jail,则不得不提ezjail,warden这两样神器。当然,正常来说ezjail用得比较广泛,而warden是PC-BSD的东西也是图形化的产物。 使用过ezjail的大神们都知道,要使用ezjail是需要主系统配合的,也就是需要主系统拥有系统原代码也就是有/usr/src这个目录 ,然后
2017-10-08 14:47:32
2346
MYECLIPSE 10 破解
2011-12-30
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人
RSS订阅