误区一：数据上链就能证明现实事实真实
比特币开发指南说明，区块通过哈希关联，节点依据共识规则验证区块和交易。这些机制支持账本记录的一致性与历史完整性，但不能直接验证链外事件。
例如，在溯源场景中，记录被纳入账本，并不自动证明实物产地、检测结果或录入内容真实。开发时需要分别回答两个问题：记录是否被修改，以及最初由谁提供、如何核验。若业务争议主要来自源头信息失真，仅增加上链环节无法解决核心问题。
误区二：交易提交成功就代表业务完成
比特币可能出现临时分叉，节点最终依据累计工作量选择有效链。因此，广播交易、交易进入区块与业务接受其确认程度，是不同环节。区块高度也不能独立充当全局唯一的区块标识。
涉及订单状态、凭证发放或跨系统同步时，应用需要区分待处理、已纳入区块和达到业务确认条件等状态，并考虑链重组后的状态修正。常见问题是“看到交易标识能否直接交付？”答案取决于实际入块情况、网络确认机制与业务容错要求，不能只凭提交接口返回成功判断。
误区三：扩容只需比较每秒交易数量
以太坊扩容文档将吞吐量、确认速度、安全性与去中心化共同列为需要关注的目标。更高的处理能力不能单独说明方案适合某项应用。
高频交互应用可以重点评估响应体验，涉及最终结算的流程则还要评估何时获得足够确定的结果。测试应覆盖完整业务路径：用户看到成功之后，后台是否仍需等待结算？网络繁忙时，费用与处理时间是否影响流程？不同测试条件下的吞吐量数字不宜直接比较。
误区四：兼容以太坊就拥有相同安全保障
以太坊扩容文档区分了安全来源不同的方案：Rollup利用主网提供安全保障，侧链采用自身的共识机制；Validium则将数据保存在主链之外。执行环境兼容，并不意味着信任前提相同。
选型时应分别检查交易由谁排序、状态如何验证、数据能否获取，以及运营方异常时用户能否退出。常见问题是“应用能直接迁移，是否意味着风险也一样？”代码兼容只能回答部分迁移问题，无法替代对结算、数据可用性和跨链环节的评估。
误区五：找到一种技术就能覆盖全部场景
开发选型应从业务需要倒推。若目标是多方核验共享记录，应先明确参与者、验证规则和争议处理方式；若瓶颈是高频操作，则需要评估链外执行与链上结算的配合条件。
一个实用的判断方法是写清三件事：必须由链验证的内容、仍需依赖外部主体的事实，以及系统异常时的恢复路径。只有这些边界明确，才能判断区块链及其扩容方案是否真正解决了场景中的问题。