yhzhu的随手记

只做前端 required 的团队，迟早会被“脏数据”反噬。本文给出前后端双保险方案：Dynamic Logic 负责交互体验（实时提示），BeforeSave Hook 守住所有入口底线（API/导入/脚本无法绕过）。覆盖错误消息策略、测试矩阵与“坏人假设”，避免脏数据进入系统。

你以为多对多必须建中间表？在 EspoCRM 里，手写 SQL 往往是你自己给自己埋雷。本文演示用纯元数据定义多对多关系：entityDefs 的 links + relationName 驱动 rebuild 自动建表。同时补齐 scopes/clientDefs/layouts，让关系在 UI 可见可配可用

外部集成的难点不是“调通 API”，而是“长期稳定运行”。本文以 Outlook/Graph 为例，讲清 OAuth 授权流程、ExternalAccount 存储、增量同步（deltaLink/skipToken）与失败恢复策略。覆盖 token 轮换、错误分类重试、幂等设计与英文日志，让集成长期稳定运行。

EspoCRM 定制的第一课不是“怎么写代码”，而是“怎么写出可升级的代码”。本文给出扩展点金字塔（Formula → Dynamic Logic → Workflow → Hook → Service），帮助选择最小侵入方案。同时梳理模块架构、目录分区、rebuild 纪律、逐文件部署、回滚与配置备份，确保长期可维护。

本文详细记录了一次OIDC认证系统中遇到的”Need admin approval”问题。用户在登录时持续收到错误提示，但使用相同令牌的独立工具却能正常工作。经过深入分析，发现问题根源在于OIDC配置中的Authorization Prompt参数设置不当

给出可复用的 CRM 选型方法：先锁定非妥协需求，再做 PoC（概念验证）与总成本核算。以 Twenty CRM、EspoCRM、Apache OFBiz 为样本，说明为何不把技术栈当硬门槛，并补上权限、审计、迁移、集成与 AGPL 合规等“后期一定会咬你”的维度。最后梳理 EspoCRM 的优势、局限与规避方式。

背景

Dify 是一款开源的大语言模型（LLM）应用开发平台，凭借其灵活的插件机制和可视化编排能力，成为企业构建 AI 应用的热门选择。我们希望通过品牌(以品牌 YZHU 为例)定制让 Dify 平台融入其企业形象，强化用户对品牌的认知。

在分布式系统架构中，服务发现、配置管理和分布式协调是三大核心挑战。目前业界主流的解决方案包括 Nacos、Consul、ZooKeeper 和 etcd，它们各自基于不同的设计理念，适用于不同的业务场景。本文将从核心功能、特性细节、适用场景等多个维度进行深入对比，帮助技术团队在实际项目中做出合适的选择。

前一段时间完成了一个基于生物识别技术的支付产品方案设计。该方案旨在通过生物特征识别（如掌静脉扫描）实现无需手机的便捷支付体验，为用户和商户提供更加安全、高效的支付解决方案。经过对敏感信息的脱敏处理，我将这个方案的核心设计理念、系统架构和关键流程记录下来，希望能为对类似技术感兴趣的读者提供一些参考和启发。本文将详细介绍该支付产品的目标、核心功能、系统架构以及交互流程，展示如何将生物识别技术与支付系统有机结合，打造一个既安全又便捷的支付生态系统。

整合了日期计算、单位转换、JSON格式化、编解码、时间戳转换、YAML/JSON转换、图片背景移除、颜色混合等8个开发者常用在线工具，提高工作效率