探索
连接社区，发现新想法。
社区
Sui is a Layer 1 protocol blockchain designed as the first internet-scale programmable blockchain platform.
热门帖子顶尖成员- 4622
- 4200
- 4038
Move is an executable bytecode language used to implement custom transactions and smart contracts.
热门帖子顶尖成员- 271
- 260
- 251
Peera is a decentralized questions and answers protocol for Web3 where users can organize and store their interests and skills, creating a common community platform
顶尖成员- 328
- 286
- 225
The InterPlanetary File System (IPFS) is a protocol, hypermedia and file sharing peer-to-peer network for storing and sharing data in a distributed file system.
热门帖子顶尖成员- 25
- 20
- 20
Walrus is a decentralized storage and data availability protocol designed specifically for large binary files, or "blobs"
热门帖子顶尖成员- 41
- 40
- 38
赏金
Sui Move 错误-无法处理交易未找到用于交易的有效汽油币
当我这样做时： //从主币中拆分付款 const [PaymentCoin] = tx.SplitCoins ( tx.object (primaryCoin.coinObjectID)， [tx.pure.u64（所需付款金额）] ); //使用原始硬币支付汽油 tx.setGasPayment ([{ ObjectID：primarycoin.coinObjectID， 版本：PrimaryCoin.Version， 摘要：Primarycoin.digest }]); tx.setgasBudget (10_000_000)； 它抱怨可变对象在一次交易中不能出现多个对象. 当我取消汽油付款时，它会抱怨 “无法处理交易 未找到用于交易的有效汽油币. ”.我的合约函数接受 .01 sui 来换取 NFT
29- +15Xavier.eth308为SuiJun 27, 2025
Sui 事务失败：为另一笔交易保留的对象
我在JsonRpcError尝试在 Sui 上执行交易时遇到了持久问题. 该错误表明对象是为另一个事务保留的，尽管我已经实现了延迟的顺序事务处理. JsonRpcError: Failed to sign transaction by a quorum of validators because one or more of its objects is reserved for another transaction. Other transactions locking these objects: AV7coSQHWg5vN3S47xada6UiZGW54xxUNhRv1QUPqWK (stake 33.83) 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 我试过了： -顺序事务执行（等待前一笔交易完成） -增加了交易之间的 3 秒延迟 而且仍然会持续出现同样的错误. 使用 Sui RPC 提交交易. 同一个对象 ID 在锁定列表中多次出现. 即使仔细安排交易顺序，也会出现错误. 是什么导致对象被 “保留” 用于其他交易？ 在交易中使用对象之前，如何正确检查对象是否可用？ 3.是否有在 Sui 中处理对象锁的最佳实践？ 这可能与交易终结时间有关吗？ 以前有人遇到过这个问题吗？如果您对Sui交易中的适当对象管理有任何见解，将不胜感激！
48 - +15Xavier.eth308为SuiJun 17, 2025
能力约束如何与异构集合中的动态字段相互作用？
我正在建立一个需要处理具有不同能力要求的多种资产类型的市场，我遇到了一些关于Move类型系统的基本问题. 我想将不同的资产类型存储在同一个集合中，但它们有不同的能力： -常规 NFT：key + store（可转让） -Soulbound 代币：key 仅限（不可转让） -具有转移限制的自定义资产 public struct Marketplace has key { id: UID, listings: Bag, // Want to store different asset types here } // This works for transferable assets public fun list_transferable( marketplace: &mut Marketplace, asset: T, price: u64 ) { /* ... */ } // But how to handle soulbound assets? public fun list_soulbound( // No store ability marketplace: &mut Marketplace, asset_ref: &T, // Can only take reference price: u64 ) { /* How do I store metadata about this? */ } 关键问题： -能力要求：使用时dynamic_field::add()，Vstore 编译时是否总是需要的？包装器类型能解决这个问题吗？ -异构存储：单个 Bag 能否存储具有不同能力集（key + store + copyvskey + store）的对象，并在运行时以不同的方式处理它们？ -类型安全：由于动态字段会执行类型擦除，因此在检索值时如何保持类型安全？存储类型元数据的模式是什么？ -见证模式：能力限制如何与幻影类型一起使用？我可以将Asset和存储Asset在同一个集合中并稍后提取类型信息吗？ 建立一个系统，在该系统中，NFT、soulbound 代币和受限资产都需要市场功能，但转移语义不同. 我尝试过包装器类型，每个能力集合有多个集合，单独的类型元数据存储. 每种方法都在类型安全性、燃气成本和复杂性之间进行权衡.
07
最新的
Sui 在简化全球贸易和供应链基础设施中的作用
简介：全球贸易是信任瓶颈 现代供应链跨越数十个国家、数百家供应商和无数文档，其中许多文件是纸质的、容易出错或无法核实的. 从集装箱追踪到海关申报和原产地证书，全球贸易受到以下问题的困扰： • 跨司法管辖区和系统的数据分散 • 欺诈性文件和伪造 • 争议解决效率低下 • 核对费用高昂且缺乏透明度 Sui 提供可编程、透明和可扩展的区块链平台，能够通过安全的自动化、可追溯性和模块化治理对整个全球贸易过程进行建模. 为什么使用 Sui 进行贸易和供应链？ 与许多通用区块链不同，Sui的面向对象架构和并行执行使企业能够： 交易应用程序中的功能优势 基于对象的建模对集装箱、货物、文档等现实世界资产进行建模 水平可扩展性处理大量事件跟踪和更新 zkLogin 身份验证安全地识别用户（海关代理人、供应商） 事件记录和排放追踪跨网络的整个监管链 自定义 Move 模块对合约逻辑进行编码（例如，原产地规则、费率） Sui 将交易文件转换为可验证的数字资产，并将流程转换为透明、自动执行的工作流程. 3.用例：使用原产地证书的国际运输 让我们来看一个简化的用例. 👟 场景：运动鞋从越南运往欧盟 利益相关者： • 胡志明市的制造商 • 货运承运人 • 海关经纪人 • 欧盟进口商 基于 SUI 的工作流程： 制造商创建的装运对象（原产地、批号、内容） 越南贸易管理局颁发的原产地证书 3.货运公司在货运转移时更新 TransitStatusObject 海关人员验证文件并对清关进行数字签名 欧盟零售商在链上收到可验证的产品 + 元数据 好处： • 所有利益相关者都可以访问防篡改的审计记录 • 没有基于电子邮件的文档共享或 PDF 伪造 • 立即遵守进出口规则 基于 Sui 的交易协议的架构 每个供应链资产或文件都成为链上的头等公民. 🔩 核心模块： • 装运对象 — 包括物品、重量、原产地、唯一编号 • CertificateModule — 验证文件真实性和颁发者角色 • CustomsApprovalModule — 海关人员可以批准/拒绝装运 • TransiteVentModule — 发出位置更新（例如，端口已扫描、已加载） 🔐 示例：用于证书验证的移动模块 模块交易:: CertificateModule { struct 证书有密钥 { origin_country：矢量， 发行人：地址， valid_until: u64， } 公共娱乐问题证书（发行人：&signer，国家：矢量）{ let cert = 证书 { 起源国：国家， 发行人：签名者:: address_of（发行者）， 有效期直到：1690000000， }; move_to（颁发者，证书）； } 公共基金验证（证书：&证书）：bool { 时间戳:: now () < cert.valid_until } } 这种逻辑确保只有受信任的机构才能签发和验证贸易文件. 互操作性：跨境实时协作 Sui 的模块化身份和客体逻辑允许在没有中央控制的情况下进行跨司法管辖区的合作： 利益相关者对 Sui 的行动 港务局将扫描事件附加到 ShipmentObject 国家出口局颁发数字签名证书 承运人更新配送预计送达时间和状况报告 海关代理在链上验证真实性和合规性 零售商检索可验证的产品历史记录 + 二氧化碳元数据 借助基于 Sui 构建的 API 和仪表板，即使是非技术参与者也可以安全地参与该协议. 欺诈预防和可追溯性 全球贸易欺诈每年导致数十亿美元的收入损失. Sui 用以下方法来对抗这个问题： • 通过 zkLogin 与身份关联的数字签名文档 • 带有时间戳事件的不可变监管链 • 基于 NFT 的带有关联认证的商品代币 • 智能触发器可防止篡改或未经授权的传输 示例：防伪 每个奢侈品代币（例如名牌手袋）都可以： • 链接到原产地证书 + 工厂批号 • 包括绑定到链上对象的二维码 • 除非经过验证的账户进行身份验证，否则禁止转售 碳信用额度和 ESG 整合 企业面临着证明可持续供应链的压力. Sui 可以： • 记录每次装运或产品单位的碳排放量 • 允许第三方（审计师、非政府组织）验证碳分数 • 将 ESG 报告附加到运输 NFT • 启用链上交易或申请碳补偿 示例：集装箱的移动日志用于估算排放，并将 carbonScoreObject 附加到产品代币上. 买家可以在购买前进行验证. 全球网络的扩展注意事项 Sui 的并行执行和低延迟使其为企业做好准备： 规模要求套装功能 每日 100,000 次更新并行对象处理 每条链 100 多个利益相关者对象级权限 实时 API 需要高吞吐量 RPC + 事件订阅 数据保留对象历史 + 链上日志 随着全球物流需求的增长，Sui 可以快速扩展. 挑战和部署策略 挑战缓解策略 司法管辖区数据限制使用特定区域的模块 + 对象标签 区块链知识有限构建用户友好的 dApps + Web UI 与传统系统集成中间件 + 链下连接器 安全 + 合规性审计 + 排放日志 + 签名证明 从一条贸易通道或产品线开始，然后逐步扩展协议和集成. 结论：在Sui上建设全球贸易的未来 Sui 以对象为中心、可编程和可扩展的架构为全球可验证的交易协议提供了基础. 借助 Sui，企业可以： • 减少文书工作、延误和欺诈 • 自动化多方工作流程 • 实现全面的可追溯性和 ESG 合规性 • 无需中央服务器即可构建共享数据层 在信任、透明度和速度决定贸易成功的世界中，Sui 不仅仅是一个区块链，它是未来供应链的信任基础设施.
0🔒 保护您的 Sui 应用程序：实用的安全清单
在 Sui 上构建令人兴奋——其以对象为中心的模型开辟了新的设计模式和更快的并行度. 但是 ⚠️ 新模型 = 新错误. 所有权错误、托管泄露或不慎的管理密钥可能会造成代价高昂的损失. 本指南为您提供了分步的安全清单 📝 以及一个实用的市场示例，以说明如何避免最常见的陷阱. ✅ 1) Sui 安全清单 🔑 最低权限 • 不要依赖单一的全局 “管理员密钥”. • 使用能力对象获得权限. • 通过多重签名或链上治理保护关键管理权力. ⚖️ 原子托管转账 • 始终将资产托管在专用清单对象内. • 使用可编程交易区块 (PTB) 进行原子交换 → 防止抢先运行和双重支出. 🛡️ 验证所有输入 • 在 “移动” 中，检查矢量长度、边界和约束. • 验证反序列化并拒绝格式错误的对象. • 切勿仅因为对象存在于链上就假设输入安全. 🧪 积极测试和模糊 • 写入负面测试：输入无效、并行更新、气体耗尽. • 为意外交易流添加模糊功能. • 在 CI 中实现自动化，尽早发现回归. 🔐 密钥管理 • 将管理员密钥存储在硬件钱包中. • 使用多重签名进行治理操作. • 团队成员离开时轮换密钥. 👀 审计与激励措施 • 对关键 Move 模块进行审计. • 启动漏洞赏金计划以进行社区测试. • 记住：外眼能捕捉到你错过的东西. 🏪 2) 实践示例：安全的市场 以下是在市场 DApp 中应用清单的方法： • 安全地托管 NFT： 卖方将 NFT 移入清单对象. 未经卖方批准，市场合同不能提取资金. • 正确处理特许权使用费： 在PTB内部计算特许权使用费，确保正确的费用分配（注意四舍五入！）. • 再入境？不在这里： Move 的资源模型通过设计可以防止复制/重入. 不过，还是要测试所有流程以确保没有逻辑漏洞. 📚 来源和进一步阅读 • Sui 文档：概念与交易 • Sui 白皮书（以对象为中心的模型） • Mysten Labs TypeScript S • Move Book • 适用于 GitHub 存储库 ✨ 要点：在 Sui 上，安全性与其说是 EVM 式的重入漏洞，不如说是所有权、权限和原子性. 如果您按照清单进行操作，则可以显著减少攻击面，同时确保用户资产的安全.
0从全新安装到您的第一个链上对象而不会卡住
*首先安装 Sui CLI 和 Move 工具链，这样您就可以构建和发布代码，然后运行 sui 客户端活动地址来确认有效的密钥对，然后使用该模板创建一个新的 Move 包这样您就不会与文件夹结构作斗争，然后编辑单个模块来定义一个带有所有者字段和一些方法（例如初始化、更新和传输）的简单对象，这样您就可以使用 Sui 了快速的对象模型，接下来你使用 sui move 编译并修复编译器显示的所有错误，因为那是你的最快的反馈循环，然后使用 sui 客户端发布 publish--gas-budget 并从输出中获取软件包和模块 ID，这样你就可以调用函数，之后你调用初始化入口函数来铸造一个对象并从交易效果中复制对象 ID，然后运行 sui 客户端对象来查看版本、所有者和字段，这样你就可以确认链写了你所期望的内容，如果你遇到 “汽油不足”，则会缩减燃气预算或请求更多测试 SUI 由于每次发布和通话都要花费汽油，如果你得到 “找不到模块”，你可能会使用错误的软件包 ID 或者忘记重建，如果你的传输因能力错误而失败，你很可能会在你打算拥有或忘记传递正确的参数形状时让对象共享，一旦基础知识奏效，你就可以在 shell 或 JavaScript 脚本中编写流程脚本，这样一个命令就可以构建、发布、铸造、更新和传输，这样可以节省时间并防止拼写错误，最后你将这个最小的示例推送到存储库中，这样队友就可以在几分钟内克隆并运行相同的步骤；通过将客体视为思维单位而不是单一的全球合约，你将你的编码方式与 Sui 存储状态的方式保持一致，这样可以保持你的思维模型干净，防止你在其他链上可能遇到的难以调试的重入或全局状态竞争，而且由于 Sui 对自有对象交易进行并行处理，你在迭代时还能看到快速确认，这使得入门过程变得更好. *
0
未回答
趋势
Sui 生态系统中的 AMM 机器人
Sui 生态系统中 AMM 机器人的主要特征和功能是什么？他们如何改进传统的交易机制，以及它们为在Sui网络上使用DeFi协议的用户提供了哪些优势？ 例如，我需要建造一个还是可以使用 Turbos Finance
94- 0xduckmove2038为SuiApr 08, 2025
👀 SEAL-我认为 Web3 数据隐私即将改变
👀 SEAL 已在 Sui 测试网上线 — 我认为 Web3 数据隐私即将改变 在 Web3 中，经常会听到诸如“用户拥有自己的数据”或“通过设计去中心化”之类的短语. 但是，仔细观察，许多应用程序仍然依赖集中式基础设施来处理敏感数据——使用 AWS 或 Google Cloud 等服务进行密钥管理. 这就引入了一个矛盾：表面上的去中心化，底层的集中化. 但是，如果有一种方法可以在不放弃权力下放的情况下安全地管理机密呢？介绍 SEAL — 去中心化机密管理 (DSM)，现已在 Sui 测试网上线. SEAL 旨在修复 Web3 最大的虚伪之处之一：在秘密使用 AWS 的同时大声疾呼去中心化 你可能会问我：海豹突击队是什么？ SEAL 是一种协议，可让您安全、分散地管理敏感数据——专为 Web3 世界构建. 可以将其视为插入 dApp 的隐私优先访问控制层. 您可以将 SEAL 视为一种可编程的数据锁. 你不只是手动锁定和解锁，而是使用Move on Sui将策略直接写入智能合约. 假设你正在构建一个 DApp，其中： -只有 NFT 持有者才能解锁高级教程 -或者，在泄露敏感文件之前，DAO 可能必须进行投票 -或者你想对元数据进行时间锁定并且只能在特定日期之后访问 海豹突击队使所有这些成为可能. 访问控制在链上 运行，完全自动化，无需管理员进行管理. 只是逻辑，直接融入区块链. 海豹突击队使所有这些成为可能. 访问控制在链上 运行，完全自动化，无需管理员进行管理. 只是逻辑，直接融入区块链. 另一个有趣的文章是SEAL如何处理加密. 它使用所谓的阈值加密，这意味着：没有一个节点可以解密数据. 需要一组服务器才能协同工作——有点像多重签名，但用于解锁机密. 这样可以分配信任，避免常见的单点故障问题. 为了保证信息的真正私密性，SEAL 会加密和解密客户端的所有内容. 任何后端都看不到您的数据. 从字面上看，它会留在你的手中，放在你的设备上. 而且 SEAL 不在乎你在哪里存储数据. 无论是 IPFS、Arweave、Walrus 还是其他平台，SEAL 都不会试图控制这部分. 它只关注谁可以看到什么，而不是东西的存储位置. 所以是的，它不仅仅是一个库或 API，它是 dApp 的链上优先、访问控制、默认隐私层. SEAL 填补了一个非常关键的空白. 让我们再分解一下. 如果你正在构建一个处理任何形式的敏感数据（封闭内容、用户文档、加密消息，甚至是锁定时间的 NFT 元数据）的 dApp，你也会遇到同样的问题： ➡️ 如何在不依赖集中服务的情况下安全地管理访问权限？ 如果没有像海豹突击队这样的队伍，大多数队伍都会： 使用 AWS KMS 或 Firebase 等集中式工具，这显然与去中心化背道而驰 或者尝试自己修补半生不熟的加密逻辑，这些逻辑通常会变得脆弱且难以审计 https://x.com/EmanAbio/status/1908240279720841425?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1908240279720841425%7Ctwgr%5E697f93dc65359d0c8c7d64ddede66c0c4adeadf1%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.notion.so%2Fharryph%2FSEAL-Launches-on-Sui-Testnet-1cc4f8e09bb380969c0dcc627b96cc22 这两个比例都不好. 尤其是在你尝试跨多个链或社区构建无需信任的应用程序时. *SEAL 使整个过程模块化和可编程. * 您可以在Move智能合约中定义访问规则，SEAL会处理其余的——密钥生成、解密批准和访问强制执行——所有这些都无需任何人手动颁发密钥或进行后端检查. 更好的是，这些规则是可审计和不可改变的——一旦上链，它们就会遵循合同，而不是人工管理员. 因此，与其问 “谁应该管理对这些数据的访问权限？”你只要问： “应该用什么逻辑来定义访问权限？” >... 然后让链条来处理. 简洁且可扩展. 这就是SEAL不仅仅涉及 “安全工具” 的原因——它是*任何关心隐私、合规性或动态访问逻辑的DApp的基础层. * 这是一个很小的转变——但它改变了我们对 Web3 中数据的看法. *与其在部署后进行加密，或依赖外部服务，不如从内置隐私开始——访问权限完全由智能合约逻辑处理. * 而这正是 Web3 现在需要的. SEAL 实际上是如何运作的？ 我们已经介绍了什么是 SEAL以及为什么 Web3 需要它，让我们来看看它在幕后是如何构建的. 这部分是技术性更强的地方，但还是不错的. 一旦你看到所有部分是如何组合在一起的，建筑就会变得很优雅. 总体而言，SEAL的工作原理是使用一种名为基于身份的加密（IBE）的技术，将链上访问逻辑与链下密钥管理相结合. 这允许开发人员将数据加密为身份，然后依靠智能合约来定义允许谁对其进行解密. 步骤 1：智能合约中的访问规则（在 Sui 上） 一切都从智能合约开始. 当你使用 SEAL 时，你需要在你的 Move 合约中定义一个名为 seal_approve 的函数，你可以在这里写下解密条件. 例如，以下是用 Move 编写的简单时间锁定规则： entry fun seal_approve(id: vector, c: &clock::Clock) { let mut prepared: BCS = bcs::new(id); let t = prepared.peel_u64(); let leftovers = prepared.into_remainder_bytes(); assert!((leftovers.length() == 0) && (c.timestamp_ms() >= t), ENoAccess); } 一旦部署，该合约将充当看门人. 每当有人想要解密数据时，他们的请求都会被根据这个逻辑进行检查. 如果通过，密钥将被释放. 如果没有，他们就会被封锁. 没有人需要干预. ##步骤 2：基于身份的加密 (IBE) 这就是魔法发生的地方. SEAL 没有加密特定钱包地址（如 PGP 或 RSA）的数据，而是使用身份字符串——这意味着你可以加密成类似的内容： -0x 钱包地址 -dao_voted: proposal_xyz -pkgid_2025_05_01（基于时间戳的规则） -甚至是 game_user_nft_holder 当数据加密后，它看起来像这样： Encrypt(mpk, identity, message) -mpk = 主公钥（众所周知） -身份 = 逻辑定义的收件人 -消息 = 实际数据 之后，如果有人想解密，密钥服务器会检查他们是否符合政策（通过链上的 seal_approve 调用）. 如果获得批准，它将返回该身份的派生私钥. Derive(msk, identity) → sk Decrypt(sk, encrypted_data) 然后，用户可以在本地解密内容. 因此，无需提前知道谁将解密即可完成加密. 您只需定义条件，SEAL 稍后再计算其余部分. 它是动态的. ##第 3 步：密钥服务器 — 脱链，但未集中化 你可能想知道：谁在拿着这些万能钥匙？ 这就是 SEAL 的密钥服务器的用武之地. 可以把它看作是一个后端： -持有主密钥 (msk) -关注链上合约（比如你的 seal_approve 逻辑） -仅在满足条件时才发出派生密钥 但是——这是关键——海豹突击队不只依赖一台密钥服务器. 你可以在阈值模式下运行它，在发放解密密钥之前，需要多个独立服务器达成一致. 例如：五分之三的密钥服务器必须批准请求. 这避免了中心故障点，也允许在密钥管理层进行权力下放. 更好的是，将来SEAL将支持MPC（多方计算）和基于飞地的设置（例如TEE），因此您可以在不影响可用性的情况下获得更强的保障. ##步骤 4：客户端解密 将密钥返回给用户后，实际的解密将在用户的设备上进行**. 这意味着： -服务器永远看不到你的数据 -后端从不存储解密的内容 -只有用户可以访问最后的消息 这是一个可靠的隐私模型. 即使有人破坏了存储层（IPFS、Arweave 等），如果不传递访问逻辑，他们仍然无法读取数据. 以下是快速思维模型： 这种结构使您可以轻松构建访问规则不是硬编码的去中心化应用程序，它们是动态的、可审计的，并且完全集成到您的链逻辑中. ##SEAL 背后的团队 SEAL 由区块链安全社区的知名人物Samczsun领导. 他曾是Paradigm的研究合伙人，曾审计过多个生态系统并将其从重大漏洞中拯救出来. 现在，他全职致力于将 SEAL 建成 Web3 隐私基础设施的核心部分. 凭借他的背景和信誉，SEAL 不仅仅是另一个实验工具，它是一次严肃的尝试，旨在使去中心化数据隐私既实用又可扩展. 随着 SEAL 在 Sui 测试网上线，它为 Web3 应用程序如何管理机密带来了新的标准. 通过结合链上访问控制、阈值加密和客户端隐私，SEAL 为去中心化数据处理提供了更值得信赖的基础. 无论你是在构建 dApp、DAO 还是去中心化游戏，SEAL 都提供了一个强大的工具包，可以在不影响去中心化的前提下执行访问控制和保护用户数据. 如果 Web3 要向前发展，像 SEAL 这样的安全基础设施不是可选的——这是必不可少的
8 如何在 Move 中合并两个硬币对象？
*我想理解 Sui Network 的这一方面，因为我要么构建、调试，要么部署一些涉及这个领域的东西. 我想详细解释这个机制或功能的工作原理，以及相关的 CLI 用法、移动代码结构或架构概念. 我的目标是获得足够的清晰度，将这些知识应用到一个真实的项目中——无论是自定义智能合约、NFT系统、钱包集成还是DeFi工具. 与 EVM 链相比，Sui Network 具有独特的功能，因此我对它的与众不同之处以及它如何影响开发最佳实践特别感兴趣. 有示例代码、命令行示例或典型错误需要注意会有所帮助，尤其是在使用 Sui CLI、SDK 或在本地网络/测试网上部署时. 归根结底，我希望避免常见错误，遵循最佳的安全原则，并确保我正在开发的功能在现实条件下表现出预期. *
715