mermaid 是很强大的一个库，可以使用文本展示图表。mdbook 是一个可以通过 Markdown 格式的文章内容生成在线书籍网站。mdbook-mermaid 这个库将 mermaid 和 mdbook 粘合在了一起。 下面是 mdbook-mermaid 的一个示例， graph TD; A-->B; A-->C; B-->D; C-->D; 该插件使用 Rust 开发，可以通过 Cargo 安装， cargo install mdbook-mermaid 在首次使用 mdbook-mermaid 时，需要下载一些依赖文件和配置，使用命令： mdbook-mermaid install path/to/your/book 上面的/path/to/your/book 是你的数据路径，运行之后，将会在你的书籍 book.toml 配置文件中添加如下内容： [preprocessor.mermaid] command = "mdbook-mermaid" [output.html] additional-js = ["mermaid.min.js", "mermaid-init.js"] 插件将检测是否已配置 mdbbok-mermaid，如果已配置将跳过。否则，将添加上面的内容到 book.toml 配置文件中，并将文件 mermaid.min.js，mermaid-init.js 复制到你书籍的目录中。你可以在 src/bin/assets 目录中找到这些文件。你还可以修改 mermaid-init.js 来配置 mermaid。 最后，重新编译书籍上传即可。

音频文件处理 我们使用手机上的录音机来录制音频文件。 Android 录音机录制的音频文件格式为 mp3，如果是 amr 格式，请使用豆子工具音频格式转换功能，转成 mp3 格式文件。 IOS 录音机录制的音频文件格式为 m4a，请使用豆子工具音频格式转换功能，转成 mp3 格式文件。 我们还需要使用 ffmpeg 将 mp3 文件转成 g711a 格式文件。这个 mp3 转 g711a 功能后续会集成到豆子工具中。 mp3 转 g711a 命令： ffmpeg -i test.mp3 -acodec pcm_alaw -f alaw -ac 1 -ar 8000 -vn test.alaw 使用 ffplay 播放测试 ffplay -i test.alaw -f alaw -ac 1 -ar 8000 将制作好的音频文件存放在 asterisk sounds 目录，就可以在拨号计划中使用 Playback 应用调用它了。 配置实时数据库 今天讲解 Asterisk 如何实时将 SIP 用户写入 sqlite3 数据库。 先定义数据库表结构，我当前使用的 PJSIP 协议。 CREATE TABLE ps_endpoints ( id VARCHAR(40) NOT NULL, transport VARCHAR(40), aors VARCHAR(200), auth VARCHAR(40), context VARCHAR(40), disallow VARCHAR(200), allow VARCHAR(200), direct_media varchar(5) check(direct_media in ('yes','no')), connected_line_method varchar(10) check(connected_line_method in ('invite','reinvite','update')), direct_media_method varchar(10) check(direct_media_method in ('invite','reinvite','update')), direct_media_glare_mitigation varchar(20) check(direct_media_glare_mitigation in ('none','outgoing','incoming')), disable_direct_media_on_nat varchar(5) check(disable_direct_media_on_nat in ('yes','no')), dtmf_mode varchar(20) check(dtmf_mode in ('rfc4733','inband','info')), external_media_address VARCHAR(40), force_rport varchar(5) check(force_rport in ('yes','no')), ice_support varchar(5) check(ice_support in ('yes','no')), identify_by varchar(10) check(identify_by in ('username')), mailboxes VARCHAR(40), moh_suggest VARCHAR(40), outbound_auth VARCHAR(40), outbound_proxy VARCHAR(40), rewrite_contact varchar(5) check(rewrite_contact in ('yes','no')), rtp_ipv6 varchar(5) check(rtp_ipv6 in ('yes','no')), rtp_symmetric varchar(5) check(rtp_symmetric in ('yes','no')), send_diversion varchar(5) check(send_diversion in ('yes','no')), send_pai varchar(5) check(send_pai in ('yes','no')), send_rpid varchar(5) check(send_rpid in ('yes','no')), timers_min_se INTEGER, timers varchar(20) check(timers in ('forced','no','required','yes')), timers_sess_expires INTEGER, callerid VARCHAR(40), callerid_privacy varchar(40) check(callerid_privacy in ('allowed_not_screened','allowed_passed_screened','allowed_failed_screened','allowed','prohib_not_screened','prohib_passed_screened','prohib_failed_screened','prohib','unavailable')), callerid_tag VARCHAR(40), `100rel` varchar(20) check(`100rel` in ('no','required','yes')), aggregate_mwi varchar(5) check(aggregate_mwi in ('yes','no')), trust_id_inbound varchar(5) check(trust_id_inbound in ('yes','no')), trust_id_outbound varchar(5) check(trust_id_outbound in ('yes','no')), use_ptime varchar(5) check(use_ptime in ('yes','no')), use_avpf varchar(5) check(use_avpf in ('yes','no')), media_encryption varchar(10) check(media_encryption in ('no','sdes','dtls')), inband_progress varchar(5) check(inband_progress in ('yes','no')), call_group VARCHAR(40), pickup_group VARCHAR(40), named_call_group VARCHAR(40), named_pickup_group VARCHAR(40), device_state_busy_at INTEGER, fax_detect varchar(5) check(fax_detect in ('yes','no')), t38_udptl varchar(5) check(t38_udptl in ('yes','no')), t38_udptl_ec varchar(20) check(t38_udptl_ec in ('none','fec','redundancy')), t38_udptl_maxdatagram INTEGER, t38_udptl_nat varchar(5) check(t38_udptl_nat in ('yes','no')), t38_udptl_ipv6 varchar(5) check(t38_udptl_ipv6 in ('yes','no')), tone_zone VARCHAR(40), language VARCHAR(40), one_touch_recording varchar(5) check(one_touch_recording in ('yes','no')), record_on_feature VARCHAR(40), record_off_feature VARCHAR(40), rtp_engine VARCHAR(40), allow_transfer varchar(5) check(allow_transfer in ('yes','no')), allow_subscribe varchar(5) check(allow_subscribe in ('yes','no')), sdp_owner VARCHAR(40), sdp_session VARCHAR(40), tos_audio INTEGER, tos_video INTEGER, cos_audio INTEGER, cos_video INTEGER, sub_min_expiry INTEGER, from_domain VARCHAR(40), from_user VARCHAR(40), mwi_fromuser VARCHAR(40), dtls_verify VARCHAR(40), dtls_rekey VARCHAR(40), dtls_cert_file VARCHAR(200), dtls_private_key VARCHAR(200), dtls_cipher VARCHAR(200), dtls_ca_file VARCHAR(200), dtls_ca_path VARCHAR(200), dtls_setup varchar(20) check(dtls_setup in ('active','passive','actpass')), srtp_tag_32 varchar(5) check(srtp_tag_32 in ('yes','no')), UNIQUE (id) ); CREATE INDEX ps_endpoints_id ON ps_endpoints (id); CREATE TABLE ps_auths ( id VARCHAR(40) NOT NULL, auth_type varchar(10) check(auth_type in ('md5','userpass')), nonce_lifetime INTEGER, md5_cred VARCHAR(40), password VARCHAR(80), realm VARCHAR(40), username VARCHAR(40), UNIQUE (id) ); CREATE INDEX ps_auths_id ON ps_auths (id); CREATE TABLE ps_aors ( id VARCHAR(40) NOT NULL, contact VARCHAR(40), default_expiration INTEGER, mailboxes VARCHAR(80), max_contacts INTEGER, minimum_expiration INTEGER, remove_existing varchar(5) check(remove_existing in ('yes','no')), qualify_frequency INTEGER, authenticate_qualify varchar(5) check(authenticate_qualify in ('yes','no')), UNIQUE (id) ); CREATE INDEX ps_aors_id ON ps_aors (id); PJSIP 测试数据： ...

在沉浸于 Wails 3 开发 Mole 客户端的过程中，我不禁想起了我在 2023 年 11 月完成的一个小项目——mp-qrcode-gen。 虽然现在微信小程序后台已经集成了生成小程序码的功能，但在 2023 年，开发者想要快速、批量或者自定义参数生成小程序码，往往需要自己写脚本。于是，我用 Rust 编写了这款极致轻量的桌面工具。 一、 为什么在 2023 年做这个工具？ 当时，很多运营人员和开发者在准备线下物料（如海报）时，面临一个痛点： 接口调用门槛：微信官方提供的是 API 接口，非技术人员无法直接使用。 参数复杂：小程序码分为“受限”和“不受限”两种，参数限制各异，手动拼凑 URL 极易出错。 批量需求：线下场景往往需要针对不同页面、不同场景值生成大量图片，网页端操作效率低下。 为了解决这些问题，我选择了当时还算冷门的 Rust 语言进行开发，追求极致的性能与体积。 二、 技术选型：Rust + native-windows-gui 在那个时期，我并没有选择 Electron 这种庞然大物，而是选择了： Rust: 保证了极高的运行效率和内存安全。 native-windows-gui (NWG): 这是一个非常纯粹的 Windows 原生 GUI 库。它不包含浏览器内核，直接调用 Windows API，生成的 .exe 文件体积非常小。 三、 核心功能拆解 工具界面直观，配置完 AppID 和 AppSecret 后，主要提供两种模式： 1. 数量受限模式 (API A/B) 特点：支持输入完整的、带有超长 URL 参数的页面路径。 场景：适用于对码量要求不高（总计 10 万个以内），但需要精准携带复杂参数的场景。 2. 数量不受限模式 (API C) 特点：页面路径较短，但支持独立的 Scene（场景值）字段。 场景：这是线下物料最常用的模式，可以无限次生成，通过场景值来区分不同的线下投放点。 3. 本地化保存 点击生成后，工具会直接调用微信接口并处理返回的二进制流，将其保存为本地图片文件。无需打开浏览器，所见即所得。 ...

在自学 Rust 的那段日子里，我除了开发开源项目，还为日常工作量身定制了一些不公开的内部工具。其中最令我印象深刻的，是一个看似简单的 APK 文件上传小工具。 虽然它只是一个 Rust + native-windows-gui (NWG) 编写的单一界面应用，但它解决的两个核心生产问题，至今仍对我有着深远的影响。 一、 工具画像：极简与高效 这个工具的界面极其克制： 交互区：一个醒目的文件拖拽控件，文案提示“请把 APK 文件拖拽到这里”。 表单区：版本号、Version Code、更新描述、是否强制升级（开关）。 执行区：一个大大的“上传”按钮。 它的核心逻辑非常纯粹：校验必填项 -> 调用内部上传 API -> 上传文件 -> 返回成功或失败的对话框。 二、 故事一：消失的 60 秒与隐藏的超时限制 工具上线初期，一切运行平稳。由于办公室带宽充足，APK 的上传时间通常维持在 40 秒左右。 事故发生： APK 在集成广告后，经常会发生失败的情况，客户端弹出“超时”的报错。 排查过程： 我首先检查了后端服务，发现后端接口完全没有超时限制，服务器日志显示连接是被客户端主动断开的。 多次重复上传文件使用有线和无线对比，经排查是文件变大，由于公司无线网络波动，上传速度时好时坏，就会偶尔出现失败的情况。对比排查，发现失败的情况上传时间都超过了 60 秒。 回到 Rust 代码中，我发现当时为了追求简洁，直接使用了 HTTP 客户端的默认配置。而这个默认配置的 Timeout 为 60 秒。 解决方案： 在那个瞬间我意识到，工具不能只考虑“理想状态”。我手动将本地超时时间放宽至 5 分钟，并增加了状态提示。上传时不会再出现超时的情况了。 教训：永远不要依赖默认的超时设置，尤其是在处理文件上传这类长耗时操作时，本地的容错范围必须根据业务场景精细化配置。 三、 故事二：包名校验——把人为失误挡在门外 这是这个工具最有价值的一次功能进化。 事故发生： 有一次，同事不小心将应用 A 的打包产物当作应用 B 上传到了官网，导致用户下载后发现软件张冠李戴。这属于严重的生产事故。 排查过程： 这个客户端软件调用内部API后，会自动将上传的文件名修改为固定的软件下载文件名，显示在网站上。经测试，如果将应用A的打包产物使用应用B上传，在官网就会出现相同的情况。解决这个方法也非常简单，就是上传的时候小心细致一点，应用A使用A客户端软件，应用B使用B客户端软件。但是人总会犯错，尤其是在面对多个长相相似的 .apk 文件时。通过肉眼观察文件名来区分应用，是极其不可靠的。 ...

高并发 WebTransport 服务端性能调优：从 Linux 内核到 Go 协程实战 一、 前言 WebTransport 作为基于 HTTP/3 (QUIC) 的新一代传输协议，其性能上限远超 WebSocket。在 72 核服务器环境下，要承载 10 万+ 并发连接，单靠业务代码是不够的，必须从 Linux 内核、网络协议栈到 Go 运行时进行深度解构。 二、 Linux 内核参数：打破“万级连接”瓶颈 在默认 Linux 配置下，UDP 缓冲区和连接跟踪表是阻碍 WebTransport 性能的首要因素。 极大化 UDP 接收缓冲区 WebTransport 瞬时涌入大量 UDP 握手包，若缓冲区过小，内核会直接丢包，导致客户端频繁超时。 bash 调大系统 UDP 接收和发送的最大缓存 (建议 64MB 以上) sudo sysctl -w net.core.rmem_max=67108864 sudo sysctl -w net.core.wmem_max=67108864 sudo sysctl -w net.core.rmem_default=33554432 sudo sysctl -w net.core.wmem_default=33554432 扩大连接跟踪表 (nf_conntrack) 公网环境下，每一条 UDP 会话都会在内核留下记录。 bash 防止因连接表满导致新连接被拒 sudo sysctl -w net.netfilter.nf_conntrack_max=1048576 请谨慎使用此类代码。 ...

突破 Web 实时通讯极限：从 0 到 10 万并发的 WebTransport 实战全记录 一、 前言：为什么选择 WebTransport？ 在实时音视频、大型多人在线交互（如本项目中的 Swarm 蜂群模拟）场景下，传统的 WebSocket 面临 TCP 队头阻塞 和 握手延迟 的瓶颈。我们利用 Go (后端) + WebTransport (前端)，在 72核/256G 的服务器上实现了亚微秒级的消息处理。 二、 基础构建：渲染引擎与协议握手 项目的起手是在 HTML 中集成 PixiJS (v8) 进行高性能 Canvas 渲染，并使用 GSAP 处理方块动效。 本地化依赖：为了稳定性和加载速度，我们将 pixi.min.js 和 gsap.min.js 下载到本地。 初探流（Stream）的陷阱： 起初误区：双方都在等待对方开启流（Accept），导致连接成功但界面「死寂」。 核心方案：明确 「服务端主动开流，客户端监听接收」 的推模式。 javascript // 核心代码：客户端监听服务端开启的单向流 const reader = transport.incomingUnidirectionalStreams.getReader(); while (true) { const { value: stream, done } = await reader.read(); if (done) break; handleIncomingDataStream(stream); // 异步处理每一个推送到来的流 } 请谨慎使用此类代码。 ...