链上流动性的秘密：去中心化交易所（DEX）是如何维持深度与招揽做市商的？
在传统的中心化交易所（CEX，如币安、欧易）中，交易深度是由专业的做市商（Market Maker）在买卖盘上挂出密密麻麻的订单来维持的。然而，在完全去中心化、没有中央撮合系统的去中心化交易所（DEX）中，上亿美元的流动性和极低的交易滑点究竟是如何实现的？ 本文将结合最新行业核心数据与经典的爆仓、亏损真实惨案，为你深度拆解 DEX 维持流动性的底层逻辑，以及它们是如何在链上招揽做市商的。🧱 一、 DEX 的深度是如何维护的？（机制与数据解析）DEX 无法像传统交易所那样依赖中心化服务器进行每秒数万次的订单匹配，因此它们开创了独特的链上流动性维护机制。目前行业内主要分为三大流派： 1. 经典恒定乘积池（AMM 模式） 核心公式：X × Y = K（X 和 Y 为池中两种代币的数量，K 为常数）。 代表平台：Uniswap V2、PancakeSwap。 维护机制：这是 DeFi 的开创性发明。它不需要任何专业做市商挂单，而是让任何人都可以将两种代币（如 ETH 和 USDT）按 50:50 的价值比例存入一个公共资金池。 深度的本质：资金池的体量（TVL）决定了交易...
我在 24GB 的 Mac mini 上折腾本地大模型，最后放弃了——一场关于「理想与内存」的和解
一句话总结：我想让本地大模型接进 Hermes 这个 AI agent，折腾了大半天，撞了三堵墙，最后没成。但这趟没白走——磁盘从 22GB 清到了 73GB，脑子里那团关于「大模型到底怎么跑」的浆糊，也终于清干净了。 起点：一个朴素的念头我有一台 Mac mini（M4 芯片 / 24GB 统一内存），平时还算够用。某天冒出个念头： 能不能让本地大模型跑在自己电脑上，还接进我常用的 Hermes（一个 AI agent 客户端）？这样不用联网、数据不出门、还免费。 听起来很美好。于是我打开了 Claude Code，说：「帮我检查下这个大模型是否匹配我的电脑配置。」 故事就这么开始了。 第一站：清磁盘（意外的最大赢家）准备装 Ollama 之前，先看了眼磁盘——只剩 22GB。这点空间连模型都塞不下几个。 于是顺手做了次大扫除，结果发现电脑里全是「僵尸缓存」： 清理项释放~/.gemini/tmp 暂存14 GBnpm 缓存~6 GBVSCode 过期扩展（85 个残留版本！）20 GBGo module 缓存3 GBCursor 对话历史 DB、剪映...
MySQL 8.4 升级踩坑：列级权限与表级权限混用，导致新增表级权限对长连接不生效
在将 MySQL 从旧版本升级到 8.4 后，我们遇到了一次由权限管理引发的线上事故：账号同时存在列级权限和表级权限时，新增的表级 INSERT 权限对已经建立的长连接（TCP 长连接）不生效，直到重启使用该连接的服务、重建连接后才恢复正常。短连接（如 Cron 定时任务）则不受影响，因为每次执行都会重新建立连接。 本文记录事故的发现过程、排查思路、根因分析，以及最终采用的治标和治本方案，供同样在做 8.4 升级评估的团队参考。 说明：截至本文撰写时，我们没有在 Oracle 官方 bugs.mysql.com 和 8.4 Release Notes 中找到与本文现象完全吻合、且被官方明确确认的 bug 记录。下文”根因分析”部分是基于 MySQL 权限校验机制做出的技术推断，并非官方定论。我们已按复现步骤向官方提交 bug 报告，等待确认。 背景 数据库版本：从 MySQL 8.0.x 升级到 8.4.x（LTS） 升级前，业务账号的权限历史上是列级权限和表级权限混用的：部分表只授予了列级权限（如 GRANT INSERT (col1, col2) ON db.tabl...
行情风控阈值分析：做市滑点保护机制
视角：做市商（Market Maker）风控。分析范围限定在已获得真实数据的 7 类指标（index_type 1/2/3/4/5/6/7）。前置文档：market_wind_tables.md（4 张表的字段结构与基础调用链）。本文聚焦阈值本身的设计逻辑与做市保护效果，不重复表结构细节。数据来源：market_wind_config 全局默认配置（symbol_id=0）截图数据 + 代码静态分析，未跑线上 SQL 核对，如有出入以线上为准。 1. 问题背景：为什么做市商需要”动态滑点”做市商在撮合引擎里挂单/对手价成交时，面对的核心风险是信息不对称下的逆向选择（adverse selection）：当行情发生剧烈单边波动或盘口流动性骤降时，做市商的报价会滞后于真实市场价，被套利者/高频交易者用滞后报价薄利甚至倒贴成交，也就是常说的”被扫单””被撸滑点”。 固定滑点表（仅按保证金规模分档，见 contract_symbol_step_slippage）无法应对这种风险——平静行情下滑点太...
需求评审 & 研发交付规范
适用对象:产品、前端、后端、测试、研发小组长目的:让研发不追问就能开工、测试看完能写用例、金融需求不出资损维护:研发小组长 一、PRD 该写什么(产品交付标准)判断一份 PRD 是否合格的唯一标准:研发看完能估工时,测试看完能写用例。 做不到就是不合格,评审时打回。 必备模块#模块内容研发关注点1背景 / 目标为什么做、解决什么问题、衡量指标(如"发息成功率 99.99%")判断优先级2名词定义关键术语统一口径("持有天数""起息日"等)前后端理解一致3用户故事 / 场景流谁、什么场景、做什么、得到什么拆任务依据4功能清单 + 优先级P0/P1/P2,明确本期做 / 不做防范围蔓延5流程图 / 状态机有状态流转的必须画(申购→持有→赎回→结息)后端建模核心6页面原型 + 字段说明每字段:来源、格式、必填、校验、边界前端直接做7交互与异常加载态、空态、失败态、并发点击、超时前端最易漏8数据规则 / 计算逻辑公式、取整、时区、周期后端最易踩坑9权限 / 角色谁能看、谁能操作后端鉴权10埋点 / 数据需求统计什么前后端配合11非功能需求性能、并发量级、幂等、合规、审计架构决策...
交易策略与高级委托
通俗科普：每种委托/策略是什么、干什么用、解决什么痛点，配图直观理解。图为 SVG 图片（策略图/ 目录），在 Obsidian / Typora / GitHub / VS Code 中均可正常显示。 图例：🟢 买入 🔴 卖出 🟡 关键价位线 ⚫ 价格走势 先搞懂两件事 普通下单高级委托 / 策略谁在操作你手动买卖系统按规则自动买卖是否盯盘全靠自己盯7×24 自动盯 💡 核心痛点：人不可能一直盯着盘，情绪还容易上头——高级委托就是把”该在什么价位做什么”交给规则去执行。 1. 止盈单 / 止损单 · OCO 风控 价格上涨触及止盈线自动卖出；若下跌触及止损线则自动止损。OCO = 两条线同时守，触发一条另一条自动取消。 是什么：设好价格，涨到就自动卖（止盈）、跌到就自动卖（止损）。 干什么：不用盯盘，价格到线系统自动执行。 解决痛点：怕半夜暴跌被套、怕赚了没跑又跌回去——两头都守着，睡觉也安心。 2. 计划委托（条件单） 择时进场 现在不买，挂个条件单埋伏；价格跌到你设的位置，系...
股票代币化产品分析 - 初版
目录 执行摘要 产品分类与判断框架 用户决策清单 竞品规则与对照 市场时段、定价与风险控制 事故复盘 产品信息架构与文案规范 外链资料索引 1. 执行摘要名称中都带有“股票”的产品，可能属于完全不同的资产结构：传统证券账户中的股票、由托管资产支持的链上经济权益，或仅跟踪价格的永续合约。 因此，产品说明不能只写“支持股票交易”或“1:1 锚定股票”。必须明确： 用户持有的是股票、经济权益凭证，还是价格合约。 是否具有分红、投票、赎回和公司行动权益。 是否可转出，及其网络、合约地址、地区和平台兼容性限制。 是否有杠杆、资金费、强平与休市定价机制。 发行、托管、流动性、定价与交易平台分别承担什么责任。 1.1 核心边界不能直接划等号原因1:1 支持 = 登记股东支持方式可能是托管资产对应的经济权益，不当然赋予直接股权或投票权。可提钱包 = 跨平台通用目标平台还必须支持同一网络、同一合约资产与适用的合规范围。余额增加 = 现金分红余额变化可能来自再投资或 multiplier 调整。24/7 可交易 = 价格质量稳定传统市场关闭时，流动性、参考价与可对冲能力可能显著下降。股票...
MySQL 迁移 PostgreSQL 常见问题与避坑指南
MySQL 迁移 PostgreSQL，真正麻烦的地方通常不是 CRUD 语法。 而是迁移之后发现： 连接突然满了SQL 超时了索引不走了事务卡死了程序断线了自增 ID 冲突了同样 SQL 跑得比 MySQL 慢UPDATE 越跑表越大 所以这篇文章不从数据库理论开始，而是直接按线上常见问题横向对比。 一、先看总表问题MySQLPostgreSQL迁移时最容易踩的坑连接数可以相对较高单连接成本更高直接照搬 MySQL 连接池连接超时connect_timeout客户端 connect timeout把连接超时误认为 SQL 慢SQL执行超时max_execution_timestatement_timeoutPG 默认策略不同锁等待innodb_lock_wait_timeoutlock_timeoutSQL 本身不慢，是在等锁空闲连接wait_timeoutidle_session_timeout连接池拿到失效连接空闲事务相对不突出idle in transaction 非常危险长事务阻塞 VACUUM断线server has gone awayserver close...
Go 服务为什么“像会自动扩协程”，以及真正的风险点
结合 Kratos + net/http + gRPC-Go + database/sql 连接池，说明请求高峰时 goroutine 如何增长、什么在限制它、以及线上真正该盯什么。 一句话结论不是框架实现了“按 QPS 动态调协程池”，而是 Go 默认模型：一个并发请求（连接/流）对应一个 handler goroutine，请求结束就退出。所以并发上来时，goroutine 数会跟着涨；流量下去后，这些 handler 退出，数量自然回落。真正会“卡住上限”的，往往是 DB 连接池、超时、CPU（GOMAXPROCS）、以及有没有进程级并发保护，而不是“协程池满了”。 1. 先分清三个词：QPS、并发、goroutine很多人把“请求量上来 → 自动扩协程”理解成： QPS 翻倍 ⇒ 协程池 size 翻倍 更准确的公式是： 并发量 ≈ QPS × 平均耗时 例子： QPS平均耗时大约同时在跑的 handler100020ms~2010002s~2000 所以： QPS 高但很快返回 → goroutine 未必很多 QPS 一般但接口变慢 → g...
云原生“交通枢纽”：跟着我，5分钟从零开始死磕 Istio 服务网格
最近在复习云原生微服务架构，越学越觉得之前的自己太天真了。以前总觉得把服务拆开、用 Kubernetes（K8s）跑起来就万事大吉了。直到遇到线上要搞 5% 流量的灰度发布（金丝雀发布），或者几个微服务天天因为网络抖动报超时、而我又不知道到底是哪两个服务之间卡住了的时候，我才发现：微服务之间的网络通信和流量治理，真的是个大坑！ 在疯狂补课之后，我终于摸到了解决这个痛点的神器——Istio。今天这篇博客，我就以一个学习者的角度，把我啃下来的 Istio 核心知识点和心得整理出来，希望能帮大家一起少走弯路！🔍 重新认识：Istio 到底是个啥？在刚接触的时候，我一直有个误区，以为它和 Spring Cloud 一样，需要我往代码里导各种依赖、写各种注解。学了之后才发现自己狭隘了：Istio 是一种“服务网格”（Service Mesh），它最大的魅力就在于“代码零侵入”！用我自己的话来理解：如果说 Kubernetes（K8s） 帮我们盖好了大楼（管好了容器的生命周期），那么 Istio 就是在大楼之间拉起了智能交通指挥系统、地下保密通信光缆和全城天网监控 [istio.io]...
