Titration

氯化钠滴定（硝酸银法）在食品基质（Food Matrix）中的原理与工程解析

在食品品质管理中，盐分控制往往比酸度更“硬核”。因为盐分直接影响： 与酸碱滴定不同，氯化钠滴定的选择性更强、干扰更少，因此结果通常更稳定。 本文系统解析其化学原理、计算逻辑、干扰因素与工程意义。 一、化学反应原理 盐分滴定通常采用 硝酸银滴定法（Mohr法）。 核心反应：Ag++Cl−→AgCl↓\mathrm{Ag^+ + Cl^- \rightarrow AgCl \downarrow}Ag++Cl−→AgCl↓ 这是一个定量、1:1 的沉淀反应。 当样品中的氯离子全部与 Ag⁺ 反应后，过量的 Ag⁺ 会与指示剂（通常是铬酸钾 K₂CrO₄）反应生成：Ag2CrO4\mathrm{Ag_2CrO_4}Ag2​CrO4​ 产生砖红色沉淀，即为终点。 二、滴定本质测的是什么？ 硝酸银法测的是： 样品中的“氯离子总量” 在食品中： 氯离子几乎全部来源于 NaCl。 因此：测得 Cl⁻≈NaCl 含量\text{测得 Cl⁻} \approx \text{NaCl 含量}测得 Cl⁻≈NaCl 含量 这是它比酸度更“干净”的原因。 三、工程计算公式 通用公式：NaCl(%)=C×V×58.44×F10×m\text{NaCl(\%)} = \frac{C \times V \times 58.44 \times F}{10 \times m}NaCl(%)=10×mC×V×58.44×F​ 其中： 四、固定条件下的工程简化 若操作条件固定为： 代入：NaCl(%)=0.1×V×58.44×1010×5\text{NaCl(\%)} = …

Titration

酸碱滴定在食品基质（Food Matrix）中的原理与工程实践解析

一、引言 在食品品质管理中，酸碱滴定是评估产品酸度稳定性的重要方法之一。本文系统阐述酸碱滴定的理论基础、计算逻辑、在复杂体系中的实际意义以及常见干扰因素。 二、酸碱滴定的化学本质 1. 中和反应原理 酸碱滴定基于中和反应：酸+碱→盐+水\text{酸} + \text{碱} \rightarrow \text{盐} + \text{水}酸+碱→盐+水 在实际操作中，使用已知浓度的氢氧化钠（NaOH）溶液中和样品中的酸性物质。 若使用 0.02 mol/L NaOH，则每 1 L 溶液含有：0.02 mol OH⁻0.02 \text{ mol OH⁻}0.02 mol OH⁻ 当 NaOH 滴定至终点时，理论上：n酸=nNaOHn_{\text{酸}} = n_{\text{NaOH}}n酸​=nNaOH​ （针对一元酸体系） 三、什么是“滴定酸度”？ 在食品体系中，滴定测得的不是某一种特定酸，而是： 所有能在终点 pH 范围内被 NaOH 中和的酸性物质总量。 这一指标称为： 总滴定酸（Titratable Acidity, TA） 其本质是： 在终点 pH 条件下的“等效酸量”。 因此它是一个“综合酸度指标”，而不是单一成分分析。 四、滴定终点与 pH 的区别 1. pH …

Docker

多栈 Docker 环境：数据迁移后的卷盘点与安全清理流程

背景 在多 Compose 栈并存的环境里，迁移完成后常见现象是： 目标是：先盘点，再确认引用关系，最后最小化删除，避免误删关键数据。 核心原则 1) 先确认“新数据落点”是否稳定 迁移成功的强信号通常是：关键服务容器的持久化目录全部使用 bind mount，且映射到统一的宿主机工作目录结构。 2) named volume 的风险等级更高 在多栈环境里，named volume 很可能承载关键数据，例如： 结论：只有当卷确认“零引用”且业务已稳定使用 bind mount 时，才进入删除阶段。 盘点步骤 Step A：列出所有卷（建立资产清单） 只列出“无引用候选”（只做名单，不删除）： Step B：列出所有容器（包含已停止） 目的： Step C：从容器侧确认挂载类型（关键确认） 对“目标业务容器”查看挂载： 关注点： 若目标业务容器已完全为 bind mount，说明迁移落点基本完成。 识别“迁移搬运容器” 迁移时常用方式是： 这类容器特征： 验证方式：列出某个卷当前被哪些容器引用（最重要的安全检查）： 安全清理顺序 ① 先删“迁移搬运容器” 前提：确认这些容器不再需要、并且目标业务已稳定运行。 ② 再做“卷引用归零”验证 对每个旧卷执行： 判定规则： ③ 最后删除确认无引用的旧卷 …

Docker

OnlyOffice Docker 栈内统一与匿名卷迁移记录

背景 在使用 onlyoffice/documentserver 单容器部署 OnlyOffice 的过程中，虽然已经将常见目录（logs / data / cache / public / fonts）通过 bind mount 挂载到了用户目录，但在实际检查容器挂载点时，仍然发现 /var/lib/docker/volumes/ 下存在多组随机字符串命名的 volume。 这类 volume 并非人为创建，而是镜像在 Dockerfile 中通过 VOLUME 指令声明后，由 Docker 自动生成的匿名卷。如果不显式覆盖挂载，这些卷会默默承载真实数据，从而破坏“栈内统一、目录可迁移”的目标。 本文记录一次完整的排查与修正过程，将 OnlyOffice 的 全部持久化数据 统一收敛到单一项目目录下，并清理匿名卷依赖。 问题确认：匿名卷从何而来 通过以下命令检查容器挂载点： 可以观察到： 这些匿名卷对应的典型路径包括： 结论：OnlyOffice 内部依赖的 PostgreSQL / RabbitMQ / Redis 等组件，其数据仍然落在 Docker 管理区，而非项目目录。 目标 现有目录结构（示例） …

Docker

Docker 中应用栈数据卷重构与迁移记录

一、问题背景（抽象化） 在一台长期运行的 Linux 主机上，使用 Docker Compose 部署了多个应用栈。随着时间推移，出现了以下典型问题： 目标不是改变 Docker 的存储机制，而是： 在不破坏 Docker 设计的前提下，让数据卷“可读、可控、可迁移”。 二、总体设计原则（通用） 1. 不强行迁移 Docker 根目录 2. 明确区分三类数据 类型 处理方式 Compose / 配置文件 保留在用户可读目录 运行期业务数据 使用 命名 volume 临时 / 缓存数据 允许 Docker 自动管理 3. 通过“命名 volume”解决可读性问题 三、问题定位方法（通用步骤） 1. 列出系统中所有 volume 2. 反向确认 volume 与容器的挂载关系 通过该方式，可以明确： 四、数据迁移的通用流程 步骤 …

AI

OpenWebUI 多模态与模型管理实践记录

背景 在 OpenWebUI 中同时接入本地模型（Ollama）与云端模型（OpenAI External）后，模型列表会显著膨胀，包含大量历史版本、兼容别名与专用用途模型。本文记录一种低心智负担、可长期使用的配置与使用方式，并解释多模态能力的实际用法。 一、为什么模型会“突然变多” 当 OpenWebUI 的 OpenAI 连接中 Model IDs 留空 时，系统会直接拉取 OpenAI /v1/models 的全量结果，其中包含： 这是 API 工程级清单，并非“用户选择列表”。数量增加并不代表配置错误。 二、真正需要关注的模型类别 1. 日常文本与思考 覆盖绝大多数文本任务。 2. 多模态（图文理解） 用法：在对话中拖入图片，配合文字提问即可完成“看图说话”。 3. 图像生成（文 → 图） 说明：该模型为单向生成模型，仅用于画图，不用于聊天或分析。 4. 可忽略的模型 这些模型不影响日常使用，可完全忽略。 三、两种可行的模型管理策略 策略 A：自动更新（省心） 适合：不想维护配置、只关心可用性。 策略 B：极简清单（推荐） 在 Settings → Connections → OpenAI → Model …

AI

OpenAI API Key 管理实践：为 OpenWebUI 与 Dify 分离创建 Key

一、背景说明 在本地或自托管环境中同时部署 OpenWebUI 与 Dify 时，二者都会涉及对 OpenAI API 的调用。如果使用同一个 API Key： 因此，更合理的做法是：为不同服务分别创建并使用独立的 API Key。 二、API Key 是否可以免费创建 OpenAI 平台允许用户： 但需要注意的是： 因此，创建多个 Key 并不会带来额外的免费调用额度。 三、是否可以创建多个 API Key 结论很明确： 这使得 API Key 可以作为逻辑隔离工具，而不是计费隔离工具。 四、推荐的 Key 划分方案 针对常见的自托管 AI 使用场景，推荐至少划分如下两类： 使用场景 API Key OpenWebUI（交互式对话） openwebui Dify（应用 / Workflow / Agent） dify 原则非常简单： 一服务一 …

AI

使用 ChatGPT API 构建自托管 AI 系统：与官方 ChatGPT 的全面对比

一、两个体系的本质区别 1. 官方 ChatGPT 官方 ChatGPT 是一个面向终端用户的一体化产品，核心特点是： 用户只需登录账号，即可直接使用文字、语音、图片、文件等能力，无需关心模型选择、上下文管理或计费细节。 2. ChatGPT API ChatGPT API 是一个面向开发者和系统构建者的能力接口，核心特点是： API 更像“发动机”，而不是“整车”。 二、账号与计费体系 账号关系 计费关系 两者可以同时使用，互不替代。 三、能力对比（模型层 vs 产品层） 模型能力 在模型层面： 差异主要来自产品层封装，而非模型本身。 四、多模态能力（图片 / 文档 / 截图） 官方 ChatGPT 的表现 这些能力对用户而言是“无感”的。 API 的实际情况 当前 OpenAI 的新一代 API 已原生支持多模态： 但需要注意： API 只提供能力，不提供完整交互体验 是否“好用”，高度依赖前端是否支持： 这也是为什么多数开源前端在体验上仍与官方存在差距。 五、语音能力 官方 ChatGPT …

AI

Dify 使用入门：从安装到真正可用的最小路径

一、结论先行：Dify 是什么？ 一句话概括： Dify 是一个“将大模型封装为应用”的平台。 它本身并不提供模型推理能力，也不是单纯的聊天界面，而是位于模型之上的应用与编排层，主要作用包括： 在常见的本地 LLM 架构中，其角色可以抽象为： 简化理解： 交互层解决“如何对话” Dify 解决“让 AI 持续按同一规则工作” 二、什么时候需要 Dify？ 不适合引入 Dify 的情况 当使用目标主要是： 此时，引入额外的应用层意义不大。 Dify 的适用场景 Dify 更适合以下需求： 其核心价值在于：长期一致性与可控性。 三、学习 Dify 的正确主线 应用 → 行为规则（Prompt） → 数据接入 学习顺序非常关键。 不建议一开始接触复杂功能，应先理解 Dify 的最小工作模型。 四、第一步：创建最小可用应用 目标不是“功能完整”，而是： 核心原则 当应用能够正常调用模型并完成基本对话，即达到该阶段目标。 五、第二步：通过系统指令固定行为 Dify 的关键能力在于系统级指令。 系统指令的作用不是提示，而是长期生效的行为约束。 其价值在于： 示例结构（抽象）： 只要系统指令保持不变，模型行为就具有可重复性。 …

Docker

Docker 中拆分 Ollama 与 Open-WebUI 为独立栈的实践记录

背景 在单机环境中使用 Docker Compose 同时运行 Ollama（推理核心）与 Open-WebUI（交互界面）是一个常见做法。初期将两者放在同一个 compose 文件中管理较为方便，但随着系统逐步演进，这种方式会带来以下问题： 因此，本次实践的目标是： 在不丢失任何既有数据的前提下，将 Ollama 与 Open-WebUI 拆分为两个独立的 Docker Compose 栈，并通过一个核心网络进行连接。 设计原则 原始状态分析 在最初的一体化部署中，Docker 会自动为服务创建数据卷。拆分为多个栈后，如果未显式指定旧数据卷名称，Docker 会为新栈创建新的空卷，从而导致“历史数据消失”的错觉。 需要明确的是： 数据通常并未被删除，而是新容器未挂载到正确的旧数据卷。 因此，拆分过程中最关键的工作并不是服务启动顺序，而是数据卷的精确绑定。 拆分思路概述 整体架构被拆分为两类栈： 所有服务间通信均通过 Docker 内部网络完成，核心服务不直接对外暴露。 核心栈配置要点（示意） 核心栈的职责包括： 配置示意（省略非关键字段）： 外围栈配置要点（示意） 外围栈的职责包括： 配置示意（省略非关键字段）： 常见问题与判断方法 为什么拆分后看起来“数据没了”？ 如何判断旧数据卷是否仍然存在？ 可通过 Docker 的卷列表与磁盘占用信息进行判断。通常： 最终状态 在完成拆分与修正后，系统应达到以下状态： 总结 本次实践的核心经验可以归纳为一句话： Docker 不会替用户判断应当使用哪个历史数据卷，所有关键数据都必须显式绑定。 通过明确： …