误区一：上链就能保证信息真实
NIST《区块链技术概述》将区块链描述为具有篡改可察觉性和抗篡改能力的分布式账本，并将已发布记录不能改变的描述限定在网络正常运行的条件下。这些性质说明记录如何被共同维护，不足以证明记录对应的现实事件真实发生。
例如，在存证或溯源方案中，需要分别回答信息由谁提交、提交前如何核验、提交后如何保留证据。账本能够支持对记录的核对，但输入环节的真实性仍需业务机制保障。
误区二：任何共享数据业务都需要区块链
技术选型应先明确参与方是否需要共同维护记录，以及各方对记录控制权有什么要求。如果业务由单一主体管理，其他参与方也接受其维护结果，应先比较普通数据库能否满足需求。
当多个主体需要共享记录，又希望约束单方修改历史的能力时，区块链才具有更明确的讨论价值。适用性取决于协作关系和信任边界，不能仅凭“需要共享数据”作出判断。
误区三：分布式部署等于没有管理权
节点分散部署，并不能直接说明权限和决策权也分散。方案仍需说明谁能参与记账、谁能调整规则，以及发生争议时如何处理。
常见问题是只统计节点数量，却没有说明节点由哪些主体控制。评审时应把部署结构和治理结构分别描述，才能看清系统实际依赖哪些参与方。
误区四：扩容只需要比较吞吐量
以太坊扩容文档把交易处理能力、最终确认速度、安全性和去中心化同时纳入讨论，并区分借助主网安全性的二层方案与采用独立共识的侧链。这意味着扩容方案不能只按速度排序，也不能把所有链外处理都视为同一种安全模型。
性能验收应说明测量的是提交成功、处理完成，还是达到最终确认。对于需要跨网络交互的应用，还应明确何时可以把结果视为完成，避免将局部处理速度当作完整业务速度。
误区五：接入主网就自动拥有相同保障
评估扩容架构时，需要分别考察执行结果如何验证、必要数据在哪里取得，以及系统依赖哪些运营角色。仅有“连接主网”这一描述，无法回答这些问题。
常见问题是：已有验证机制，为什么还要关心数据？验证结果是否符合规则，与参与方能否取得核验或恢复所需的数据，是不同的工程问题。方案应明确各自的保障方式和适用条件，不能将某类技术的原则性优势直接当作具体部署已经实现的能力。