shubuzuo
shubuzuo

述而不作

All Posts in 2024.7


mongoose 类型问题

这篇博客深入探讨了在使用Mongoose模块构建MongoDB查询时遇到的类型系统缺陷问题通过代码示例揭示FilterQuery类型约束的失效现象当开发者试图为查询条件添加非法字段时TypeScript未能提供预期的类型检查反而允许代码通过编译这种类型安全漏洞可能导致生产环境的查询错误文章进一步引发对ORM框架选择的思考对比了Prisma和TypeORM的潜在替代方案但指出每个方案都存在权衡例如Prisma需要重写Schema而TypeORM对MongoDB支持有限这种类型约束的缺失暴露出Mongoose生态在类型驱动开发理念下的根本性不足文章最后抛出值得深思的问题当类型系统无法保障核心功能的安全性时开发者该如何在灵活性与可靠性之间寻找平衡点而这种类型约束的缺失是否反映了更深层次的框架设计理念缺陷这些问题的答案或许能指引我们重新审视现代开发中类型系统的真正价值--Qwen3

study work 2024 mongoose orm typescript

nginx 密码套件安全排查

在一次三级等保检测中通过nmap扫描发现nginx服务器存在SSL/TLS密码套件安全隐患,这场排查揭示了云环境安全配置的深层隐忧。当本地测试显示配置正常而外网检测却持续报错时,问题焦点逐渐从服务器本身转向了网络链路中的未知中间件——最终发现阿里云WAF的默认配置竟未禁用TLS 1.2等不安全协议,这个被运维团队忽视的"透明层"成为真正的风险源。整个排查过程如同抽丝剥茧般展示了安全验证的复杂性:当测试结果产生矛盾时如何通过定位方法论缩小排查范围?当基础设施存在多层封装时如何穿透技术迷雾?更值得深思的是,这场由配置疏漏引发的连锁反应背后,暴露出云产品链路中隐含的安全责任盲区——当WAF这类前置组件缺乏配置审计机制时,后端服务的安全加固是否注定事倍功半?这提醒我们关注云环境下的安全闭环必须超越单一组件视角,如何确保中间件链的每个环节都符合安全标准?如何在架构设计阶段就建立可验证的防御体系?这些问题或许比单纯更新密码套件列表更具现实意义。--Qwen3

2023 nginx docker centos work security cloud

因明入正理论 立论梳理

文章系统阐述了因明学中论辩的规范与要求,围绕论庄严、论堕负、论出离、论多所作法四大核心展开。论庄严强调立论者需具备五种修养(调善、信受、无畏、智德、应供)及二十七种功德(如众所敬重、辩才无尽等),以语言德行与智慧调和赢得信服;论堕负指出立论失败的三种情形(舍言、言屈、言过),其中舍言指主动放弃论点,言屈包含十三种因情绪或逻辑混乱而败北的表现,言过则为语言表达的九种谬误(如杂乱、粗犷、不显了等);论出离要求立论者通过三种观察(得失权衡、时众判断、善巧评估)决定是否展开论辩,强调以利益众生为根本考量;论多所作法则提出三种能力(善知自他宗、勇猛无畏、辩才无竭),确保论辩的广度与深度。全文构建了从修养到实践、从规范到策略的完整论辩体系,旨在引导论者以理性智慧维护正法。--Qwen3

zhongzhe study weishi 2024 logic debate

丐版 mongodb 全文搜索

本文探讨了在NestJS框架与Mongoose中通过社区版MongoDB实现中文全文搜索的实践方案。面对社区版MongoDB缺乏原生中文分词引擎的挑战文章展示了如何通过Node-RS的jieba分词库构建自定义文本处理链并结合Docker容器化部署方案实现本地开发环境的快速初始化。技术实现中通过监听数据变更事件触发回写机制解决了中文文本的分词与索引构建问题同时涉及多实体数据检测、值对象处理等复杂场景的适配方案。文章深入分析了基于MongoDB的全文搜索方案相较于Elasticsearch等专业搜索引擎的优劣权衡揭示了在不同业务场景下选择数据存储方案时需要考虑的技术取舍。当面对中文分词的精度优化与多实体数据关联查询的性能瓶颈时是否可以通过混合架构设计实现最优解?在数据一致性要求较高的场景中如何平衡实时索引更新与系统吞吐量之间的矛盾?这些未解的命题或许正是推动技术边界的关键。--Qwen3

mongodb study node docker work nest fulltext search

openapi client 生成

在软件开发中自动生成SDK已成为提升效率的关键实践通过OpenAPI元数据驱动的代码生成不仅减少了重复劳动更在类型安全和接口一致性上提供了保障作者深入比较了AutorestSwagger-codegen-cli等工具后发现其各自局限性Autorest虽集成度高但缺乏浏览器环境适配Swagger-codegen-cli生成的代码存在依赖缺失而@hey-api/openapi-ts凭借对NestJS和Vue生态的友好支持成为更优解其通过智能识别DTO实体类实现类型复用的自动化流程在CI/CD中构建SDK子仓库的实践则进一步验证了生成代码的可维护性当开发者在pinia中直接导入生成的authLogin方法时类型校验与请求拦截器的自动注入展示了生成式SDK的优雅体验值得注意的是当前生成工具仍存在参数校验自动化的空白如何设计标准化的校验规则并将其嵌入代码生成流程或许将成为下一代SDK生成器的重要突破点而当后端接口开始规范输入输出结构时前端开发是否能完全摆脱手写请求逻辑这个边界又将如何重新定义--Qwen3

study vue github ci-cd work 2024 openapi swagger