[Bug] Embedded chatbot drops numeric zero defaults and required number values

快速结论：当 Dify 自托管实例的嵌入式聊天机器人（Embedded Chatbot）配置了“必填 Number 输入”，且用户传入或应用默认值为数字 0 时，0 会被当成“空值”处理——URL 参数被覆盖、输入框显示为空、启动对话被必填校验拦截。优先排查 web/app/components/base/chat/embedded-chatbot/ 下的真值（truthiness）判断，而不是模型或后端服务。

适用环境：Dify 1.17.1，main 分支 commit 7b0660b4；自托管（Self Hosted，Source 部署）。Issue 未提供操作系统、Python、Node、显卡等环境信息，故不列出。

最快修复方案：暂无确认的一步修复方案。Issue 未合并修复 PR，仅指出四处真值判断是根因，并建议用显式比较（如 ?? null、=== undefined || === null || === ''、variable in obj）替换 || 判断，可优先尝试按此思路改造。

注意事项：仅修 embedded-chatbot 会遗漏同源的 chat-with-history 流程（其存在完全相同的 item.default || null、!newConversationInputsRef.current[variable]、!inputsFormValue?.[variable] 写法）；针对 #43240 的 PR #43241 只改了共享的 workflow 校验 hook，不覆盖本 Issue 涉及的路径。以上修复思路均来自 Issue 讨论与建议，尚未经官方合并验证。

问题场景

在 Dify 自托管实例中创建带嵌入式聊天机器人的应用，并配置一个“必填（required）的 Number 类型输入变量”，且该变量的默认值为数字 0；或者通过 URL 参数向嵌入式聊天机器人传入 0（例如 n1=0）。渲染嵌入式聊天机器人的输入表单时即可复现：输入框显示为空，或点击开始对话被拦截。Issue 作者在 main 分支上编写了聚焦回归测试，无需模型供应商即可复现，结果为 3 failed | 49 passed (52)。

报错原文

[Bug] Embedded chatbot drops numeric zero defaults and required number values

回归测试输出（节选自 Issue 的 Verification 部分）：

Test Files  2 failed (2)
Tests       3 failed | 49 passed (52)

失败用例覆盖三类场景：URL 参数为 0、必填 Number 为数字 0、以及从 context 渲染数字 0。

原因分析

最可能的原因是嵌入式聊天机器人的输入流程在多处使用了 JavaScript 真值判断（truthiness check），导致数字 0 被当作假值（falsy）而等同于空值。Issue 中点名了四处位置：

web/app/components/base/chat/embedded-chatbot/hooks.tsx：Number 默认值计算写作 convertedNumber || item.default || item.number.default，当解析出的 convertedNumber 为 0 时会继续向后取应用默认值，因此 URL 参数 n1=0 会被应用默认值覆盖。
同一文件：新会话输入初始化使用 item.default || null，把默认值 0 替换成了 null。
同一文件的 checkInputsRequired：必填校验写作 !newConversationInputsRef.current[variable]，使必填 Number 字段取值为 0 时被判为“空”；chat-wrapper.tsx 中 inputDisabled 的 if (!inputsFormValue?.[variable]) hasEmptyInput = label 同理。
web/app/components/base/chat/embedded-chatbot/inputs-form/content.tsx：渲染写作 value={inputsFormValue?.[form.variable] || ''}，因此数字 0 被渲染成空白输入框。

此外，同源的 chat-with-history 流程（hooks.tsx 与 inputs-form/content.tsx）存在完全相同的写法，因此只修 embedded-chatbot 很可能留下同样的缺陷。Issue 中的修复思路是：渲染层参考 before-run-form/form-item.tsx 的 value == null || value === '' ? null : Number(value)，改用 value === undefined || value === null || value === '' ? '' : value；默认值改用 item.default ?? null；对象取值改用 variable in obj ? obj[variable] : ...。这些均为讨论中的建议方案，尚未被合并验证。

环境排查

确认 Dify 版本：Issue 报告为 1.17.1，main 分支 commit 7b0660b4；不同版本代码行号可能不同。
确认部署方式为 Self Hosted（Source），并定位到实际的 web/app/components/base/chat/embedded-chatbot/ 源码路径。
确认是否同时使用 chat-with-history 流程，以判断修复范围。
Issue 未提供操作系统、Node、Python、CUDA、显卡、依赖版本等信息，这些项目无需在本次排查中对比。

解决步骤

按 Issue 复现路径确认问题：建立带嵌入式聊天机器人、含必填 Number 变量的应用，将默认值设为 0，或通过 URL 传入 n1=0，观察输入框渲染与启动对话行为。
在 web/app/components/base/chat/embedded-chatbot/hooks.tsx 中，定位 Number 默认值计算 convertedNumber || item.default || item.number.default，改为能保留 0 的显式判断（例如优先判断 convertedNumber 是否为 undefined/null）。
在同一文件中，将新会话初始化 item.default || null 改为 item.default ?? null。
在同一文件的 checkInputsRequired 中，将 !newConversationInputsRef.current[variable] 改为同时排除 0 的判断（参考 PR #43241 的写法：!inputs[variable] && inputs[variable] !== 0）。
在 chat-wrapper.tsx 的 inputDisabled 中，对 !inputsFormValue?.[variable] 做同样处理。
在 inputs-form/content.tsx 中，将渲染表达式 inputsFormValue?.[form.variable] || '' 替换为显式的空值判断（如 value === undefined || value === null || value === '' ? '' : value）。
同步检查并修复 chat-with-history 下对应的 hooks.tsx 与 inputs-form/content.tsx，避免同一缺陷残留。
运行 Issue 中提到的回归测试（URL 参数为 0、必填 Number 为 0、context 渲染数字 0）验证。

验证方法

重新渲染嵌入式聊天机器人输入表单：类型为 Number、默认值为 0 的必填字段应显示为 0 而不是空白；通过 URL 传入 n1=0 时应保留 0 而非被应用默认值覆盖；点击开始对话时该字段不应被必填校验拦截。若已编写或使用 Issue 中的三个聚焦回归测试，应全部通过（对照复现时的 3 failed | 49 passed）。