Scaffold HBAR选的模板为什么没生效？核npm透传、框架能力与附加安装

开始前准备

• 准备自己已有的脱敏配置、材料或响应记录，保留产品版本、网络、字段和采样时间；缺项保持未知。

1. 固定模板来源与目标

记录CLI版本/分支、项目目录名、模板key和目标网络；内置模板从templates/*分支动态获取，外部模板用owner/repo或owner/repo#branch。文档提供testnet/mainnet选项，但当前任务只整理配方，名称中有桥或付款不表示已完成对应网络动作。

检查结果：模板来源、分支与网络已分列；没有把动态列表当固定发布数量。

• 依据：Hedera：Scaffold HBAR当前模板、能力清单与CLI参数 ↗
• 依据：create-scaffold-hbar：CLI选项与默认附加安装 ↗

2. 先看模板能力再配框架

用当前模板表核框架，例如payments-scheduler为Foundry、cross-chain-dca为Hardhat、hedera-demo为Next.js原生服务且无Solidity。外部模板可在template.json的create-scaffold-hbar.capabilities声明frontend、solidityFramework、packageManager，并用defaults给默认值；这份manifest是可选的，缺失不能自行补出支持能力。

检查结果：所选框架符合当前模板说明；manifest缺失/自定义能力分别标记。

• 依据：Hedera：Scaffold HBAR当前模板、能力清单与CLI参数 ↗

3. 核npm与npx的参数位置

官方仓库示例npm create scaffold-hbar@latest my-app -- --template org/repo把--放在npm透传边界；少了它，npm可能把--template当自己的设置并生成默认模板。npx create-scaffold-hbar@latest my-app --template org/repo无需这一边界。把已保存命令按入口逐项拆开，不能只看到文字template就断言CLI收到了参数。

检查结果：npm透传分隔符与npx入口已区分；实际生成模板若无记录仍保持待核。

• 依据：Scaffold HBAR：npm参数透传与项目布局 ↗

4. 把默认值与两种附加安装分开

当前文档--yes示例用blank、Foundry、testnet默认值；显式frontend/solidity-framework可为none。--skip-install只跳依赖安装，--skip-hedera-skills才跳默认Hedera Skills；CLI README称--yes/--ci默认装技能，且--install-hedera-skills不可与--skip-hedera-skills合用。配方应明确这两个开关，不能把跳依赖理解为跳过一切附加动作。

检查结果：默认选择、依赖安装与技能安装各有独立记录；互斥选项未并用。

• 依据：Hedera：Scaffold HBAR当前模板、能力清单与CLI参数 ↗
• 依据：create-scaffold-hbar：CLI选项与默认附加安装 ↗

5. 核包管理器冲突和产物路径

当前Hedera文档称CLI项目可选npm/Yarn，模板README也区分CLI与clone main的Yarn工作区；CLI README仍称仅Yarn，故保留所用版本及生成package.json/锁文件证据再判。LayerZero外部模板另用pnpm。源码位置为packages/hardhat或foundry与packages/nextjs；deployedContracts.ts是部署后生成的ABI文件，缺它不能凭脚手架配方认定部署成功。

检查结果：包管理器依据具体模板/版本判；源码与部署后ABI产物已分开，冲突未猜测消除。

• 依据：Hedera：Scaffold HBAR当前模板、能力清单与CLI参数 ↗
• 依据：create-scaffold-hbar：CLI选项与默认附加安装 ↗
• 依据：Scaffold HBAR：npm参数透传与项目布局 ↗

怎样确认完成

• 保存输入、字段/单位、判定结果及待核差异；官方方法已核，实际客户端行为和本人服务权限未验证。

常见错误与边界

• npm命令中的--和模板名中的#branch承担不同作用，不能互换。
• 教程整理输入与文件核对方法，模板生成、安装或部署结果需要各自的实际记录。