一、明确适用范围与技术层次
“京杭区块链技术需要注意哪些问题”中的“京杭”尚无法对应到已核实的具体技术方案，因此不能据此判断其使用哪条链、是否支持智能合约或通过安全审计。以下讨论通用原理：比特币开发者指南涉及账本验证与共识，以太坊开发者安全文档涉及智能合约防护，两者不能直接等同于某个项目的实现。
二、账本一致不等于业务逻辑正确
比特币开发者指南说明，全节点按照共识规则独立验证区块；区块通过前一区块头的哈希连接，交易则遵循未花费输出等验证规则。这些机制帮助网络识别不符合规则的记录。
需要区分两个问题：记录是否符合网络规则，以及业务设计是否符合预期。共识能够约束前者，却不能替代应用层的规则检查，不能仅凭“已经上链”就认定业务逻辑正确。
三、注意分叉与记录标识
比特币可能出现同一高度存在多个区块的情况，节点在有效分支之间依据累计工作量选择链。因此，区块高度不能作为全局唯一标识，标识区块通常需要使用区块头哈希。
这一说明适用于比特币的相关机制，不能直接套用到所有区块链。评价具体系统时，应先明确其共识规则，再理解记录确认和分支选择的含义。
四、公开调用必须配合权限控制
以太坊智能合约安全文档强调，公开或外部函数需要对敏感操作设置访问控制，并检查输入、调用身份与状态条件。角色划分和多签可以分散管理权限，但不能保证风险消失。
常见误区是把函数可见性当作完整授权机制。允许外部调用，不代表允许任何人修改关键参数；反过来，把函数设为私有，也不等于链上数据获得保密保护。
五、测试与审查不能互相替代
合约安全检查应结合单元测试、属性测试、静态或动态分析以及独立审查。测试通过，只能说明已检查的场景符合预期；审计也不能证明所有漏洞都已消除。
形式化验证的结论受规格、模型和假设约束，不能笼统理解为整个系统绝对安全。审查结果还应对应明确的代码版本，后续修改不能自动沿用此前结论。
六、部署前考虑维护边界
已部署合约的代码通常不能像普通应用一样直接修改，因此必须提前考虑缺陷处理与管理责任。如果系统设有升级或暂停机制，也要将这些权限纳入安全检查。
总体而言，应分别核对底层共识、应用逻辑和管理权限。底层账本可靠，不意味着合约必然安全；合约经过审查，也不意味着管理员操作不会成为风险来源。