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