一、把区块链当成通用数据库替代品
讨论区块链开发场景有哪些常见误区，首先要区分业务需求与技术能力。比特币开发指南介绍的公共账本，重点是按照共识规则验证交易、防止重复花费并维护交易历史。这不意味着区块链天然适合所有数据存储任务。
适用性判断应从问题出发：业务是否需要多方独立验证同一份记录？如果只是单一主体维护内部数据，不能仅凭“记录可追溯”就认定必须使用区块链。还应比较系统复杂度、数据访问方式和维护负担。
二、只看吞吐量，不看安全与去中心化
以太坊扩容文档将提升处理能力与保持安全、去中心化并列讨论，并强调节点参与门槛的重要性。因此，吞吐量更高并不足以单独证明方案更适合业务。
常见问题是：两个方案都声称处理速度快，应如何比较？需要先统一衡量口径，区分请求被接收、交易被处理和结果达到最终性。用户界面更快显示成功，不等于底层结算保障同步增强。
三、把所有链下方案都叫作同一种二层网络
以太坊扩容文档区分了不同链下方案：Rollup利用主网提供的保障；侧链采用自身的共识机制；Validium采用有效性证明，但数据不存放在主网。与主网连接，并不代表安全假设完全相同。
开发选型时，不应只看“兼容以太坊”或“费用较低”等描述。更重要的是分别明确交易由谁处理、数据在哪里取得，以及业务依赖哪些运行条件。这些问题适用于需要比较不同扩容架构的应用。
四、把交易入块等同于永久确认
比特币开发指南说明，网络可能短暂出现竞争区块，节点随后依据有效链的累计工作量选择链。因此，交易进入某个区块与获得更稳固的确认并不是同一件事。
应用中的“已提交”“已入块”和“达到业务确认条件”应有所区分。尤其是需要依据链上结果更新业务状态时，不宜把第一次观察到的结果直接当作永不变化的事实，也不能将某条链的确认规则机械套用到其他网络。
五、用区块高度作为唯一标识
比特币开发指南还指出，分叉期间同一高度可能出现多个区块。高度表达的是位置，不足以唯一确定区块身份。
这一区别适用于浏览器、索引服务和账本同步系统。按高度查找数据，与确认某个具体区块，是不同的需求；涉及记录关联和状态核对时，应明确所指网络及区块哈希，避免把位置相同误认为对象相同。
六、认为更换底层方案就完成了开发
扩容解决的是部分容量与成本问题，不会自动替应用定义成功状态、异常处理和数据核对方式。技术名称也不能替代业务验收标准。
更稳妥的做法是先明确业务需要什么保障，再检查架构是否满足：什么状态可对外展示为完成，依赖的数据能否取得，网络状态变化时如何保持记录一致。先厘清这些边界，再比较性能指标，才能避免只解决速度问题，却留下正确性问题。