为什么国内 B 端买家要源码买断，而不是 SaaS 订阅

国内 B 端买家拒绝 SaaS，多数时候跟付不付得起年费没关系。他不愿意把“业务能不能继续跑”这件事，挂在一个随时可能涨价、停服、断供的外部账号上。源码买断卖的是控制权，代码只是控制权的载体。

先看买家自己怎么写

2026 年 10 月，我把互站网的源码求购区抓了一遍：这个板块累计 9,033 条，我取了约 1,800 条逐条读，其中 887 条和多商户、供应链、预约、招工这类常规业务系统相关，55 条明确点名 Java 或 uniapp——点名技术栈的只占 3%，买家按业务找货，不按语言找。除了数字，更值钱的是买家自己写下的交付要求，下面几句是原话：

“全开源、无加密、无 license、无域名绑定。”

“无授权 license、无域名/机器绑定。”

“域名授权形式的请勿联系。”

“必须要有演示。”“发演示账户，能看中，就会通知财务。”

“我不懂技术，需负责帮我部署到阿里云服务器并调试上线（可支付部署费）。”

“以后我能自己开发和维护。”

前三条在划同一个边界：不许锁。后三条说明他真正卡在哪：看得见东西、装得起来、接得住手。9,033 条是该板块当时显示的总量，约 1,800 条是我抓下来逐条读的样本，887 和 55 是在样本里按我自己的口径筛出来的，不是平台官方统计。合起来是同一件事——买家要的是所有权，而且他要的所有权，得能落成后续那些动作：自己编译、自己部署、自己接手。

这不是国内客户“不尊重软件”。愿意一次拿出几千到几万买断源码的人，是在认真做长期生意，只是把账算得很清楚：

• 年费交了三年系统还是别人的；
• 服务商不做了数据导不出来；
• 想改一个字段要排队加钱；
• 公司注销或者换服务器，授权就失效；
• 想找本地的技术人员接手，代码是加密的。

任何一条发生，损失都不是几千块年费能覆盖的。

还有一层差别在客户的账上。订阅年费是当期费用，定制开发和买断在很多客户那里能算成资产，前提是合同把权属写清楚。这也是合同里知识产权那一条不能走形式的原因：对方会计看不到权属，这笔钱就只能当费用花掉，老板的偏好自然不一样。

我那 1,800 条样本里写明预算的，最高的几条是：¥38,888（Java 智慧养老）、¥20,000（零工通）、¥10,000（蓝领招工）、¥8,888（SaaS 供应链商城）。这个板块源码成交的笔均只有 ¥885——平台成交页口径，含模板小件，时间窗是抓取当月。也就是说，愿意为“不锁”付钱的人确实存在，但付大钱的前提是你交付的是能上线的系统，不是一个压缩包。

四种交付方式，卖的不是同一样东西

后两行的区别值得单看。很多技术人把“源码买断”做成“发一个压缩包”，然后抱怨客户拖着不付款。买家要的是能跑起来的结果：环境装好、数据迁好、权限配好、演示过、验收单签了。源码是交付物之一，不是交付本身。

一份完整的买断交付，至少要让买家的技术人员在没有你的情况下完成一次发布。验的是这件事，不是仓库里有多少行代码。

仓库要能编译，依赖版本锁定，构建脚本可用；数据库要有建表脚本、初始化数据、升级脚本，而不是只给一个导出的库；部署文档要写到端口、目录、账号、启动顺序。

第三方账号要按三类分别写清，不能打包成一句“完成移交”：

• 能过户的——域名、支付商户号。商户号过户受平台审核限制，要留出周期，兜底是买方新申请；
• 必须重建的——ICP 备案不能移交，只能主体变更或注销重备，中间有空窗，空窗期的责任写进合同；短信签名要重审，地图 key 换新，小程序主体变更要走公证加平台审核；
• 数据迁移的——对象存储、数据库。

这条最容易在上线后变成事故：代码给了，支付商户号还挂在乙方名下，客户收的钱进不了自己的账户。合同里加一句：因平台或管局审核导致无法过户的，乙方协助重建，不构成违约。

第三方依赖还要离线归档：maven、npm 的仓库压缩包或 vendor 目录随源码交付，验收时让买方在只连内网源的环境完成一次构建。镜像下架、私服失效，两年后编译不过，买断的核心承诺就落空了，而那时你多半收不到第二次钱。

还有构建和发布流程。谁来打包、镜像存在哪、版本号怎么定、回滚用哪个包，这些不写在交付清单里，下一次升级就会来找你。找你不是坏事，但如果合同里写的是“已买断”，每一次求助都会变成一次关于边界的争论。

所以买断的交付清单应该和验收单钉在一起：每一项都有交付物、有接收人、有日期。代码是其中一项，不是全部。

不是所有客户都该卖源码。单店、预算低于 ¥3,000/年、没有 IT 的，他买了源码也维护不了，最后还是回头找你，不如先订阅。只想先用起来、不愿承担部署成本的，先跑通再谈私有化。还有电子发票、支付通道、地图服务这类上游变更频繁的能力：卖断之后每年都有一次“要不要付费升级”的谈判，客户小就不值得——这类客户要么维持订阅，要么报价时预收年度变更包，把那条计费项落到合同里。

判断口径就一句话：他有没有“自己掌控”的需求，以及有没有能力接住这个掌控权。两者都有，卖买断；只有前者，卖私有化部署加年费；两者都没有，卖订阅。

“不绑域名”为什么是硬要求

我上一版方案把域名绑定授权当成防传播的核心手段，这个判断是错的。

对买家来说，域名绑定意味着换域名要找你，迁服务器要找你，你不做了系统就废了，他想让本地团队接手也接不了。这四条正好否定了“买断”的意义，花的钱越多越不能接受这种不确定性。在源码市场，挂上绑定就是直接出局。

那防传播靠什么？锁是锁不住的，只能把重心挪到这四层，而且顺序不能颠倒。

法律层排在第一：软件著作权登记（几百块、数周，赶在交付前提交；下证之前以合同加交付记录为权属证据）、授权协议。技术手段失效的时候，法律证据才是能拿出来的东西。技术层只做溯源：构建时把交付流水号和买家标识的哈希注入构建产物和初始化脚本的固定位置，交付台账登记交付 ID、买家、版本、水印串、日期；注释级水印在买家二开后留不住，只能当辅助，不作为追责依据，且不限制运行。商业层是主力：持续更新、部署服务、二开服务，交付出去的版本不等于你内部在用的版本。买家买的是当前版本加 30 天售后，要用新功能就得继续付费。结构层次之：真正值钱的能力放在服务里，别藏在代码里等人解密。只做得起一件，就先做著作权登记。

在源码市场，你卖的必须是运行上不设锁、权属上写得清的东西；传播的拦截靠授权协议和“我一直在更新，你的旧版本会落后”，不靠运行时校验。

常见的锁不止域名绑定：

• 机器码绑定，换服务器就失效；
• license 文件带到期日，第二年不续费系统直接打不开；
• 核心类加密或混淆，能运行但不能改；
• 心跳授权，外网持续断连超过宽限期就进不了后台；
• 把关键逻辑放在自己的云函数里，本地部署只是个壳。

这些手段在演示阶段都看不出来。买家第一次遇到，往往是他最急的时候：大促前换服务器、备案被注销、原开发者转行、公司网络改成全内网。任何一次都足以让业务停摆，而停摆的损失不会因为你“只是防盗版”就少一分。

所以求购区里那句“域名授权形式的请勿联系”，是买家提前划掉的筛选项。买家在见你之前，已经把不能接受的交付方式划掉了。你再去解释“我们的锁很安全”，等于告诉对方你没读懂需求。

反过来说，不锁并不等于裸奔。合同、著作权登记、源码水印、持续更新，这四样加起来比任何加密都更接近真实防护。锁只防住了愿意付钱但想换服务器的人，防不住真正想盗版的人。

合同里必须写清楚的七件事

我经手的国内 B 端项目纠纷，大多卡在交付边界，不在代码。这七条建议直接进合同。

源码范围要写到模块和端：后台、小程序、APP 分别包含什么，是否含数据库脚本、部署文档、接口文档。只写“全套源码”等于没写，后面一定会为“小程序算不算”吵一次。

授权范围要写清买断之后能不能无限部署、能不能二开、能不能转售。我的写法是“仅限买方自用或自营项目”，转售另签白牌协议；涉及区域代理的，另附区域范围、独家期限与冲突处理条款。不写这一条，买家转手卖给同行，你没有任何依据。

部署责任要落到人：谁提供服务器、谁负责备案、含不含首次部署、远程还是现场、差旅谁出。很多单子就是卡在“我以为你会装”。

验收标准要附功能清单、性能口径、数据迁移范围、验收期限，以及逾期未提出书面异议视为通过的条件——书面异议以合同载明的邮箱或地址送达为准。没有清单的验收，最后都会变成“感觉还不行”。

售后边界要写清 30 天内修 bug 免费——bug 指与已验收功能清单的偏差，争议以清单为唯一基准；新需求、第三方接口变更、服务器和网络问题分别怎么计费。售后这条，写的是成本。

知识产权与保密要分清原有产权和定制部分，以及你能不能把通用能力复用到别的项目。你不可能为每个客户从零写一套系统，复用本来就是交付能力的一部分。这一条现在不写，将来做白牌就是争议。

第七条是价款与交付顺序，前六条没有它会全部被架空：定金 30%，演示通过付至 70%，部署与验收通过付清，凭结清凭证释放全量仓库和账号；验收期间买方持可编译副本用于验证，全量源码是尾款的押品。纠纷大多卡在交付边界，但先卡住的从来是钱。

报价的现实区间

按 2026 年国内公开求购和交付市场的口径给个参考，不是定价标准。表一是市场成交带，含我本人不接的部分；我自营的参考价和它对不上，运维比例 10–15% 是纯远程、10–20% 含驻场，区间差异都有出处。

低于 ¥2,000 的纯定制我不建议接。沟通、部署、售后这些固定成本摊下来，这一单大概率是亏的，跟看不看得起小单无关。

买断不是把关系一次卖断。一次性收入覆盖不了长期支持，所以报价时要把首年运维写进去，或者明确写成不含。含与不含都能签，怕的是合同里没写，第一次紧急改动就会变成争论。

后续收入大概来自四类，各自的口径要能报出口：版本更新按首价的 15–20% 每年，只发新版本不含部署；部署与迁移按次报；二开按人天计，低于一人天的小改并入运维包；白牌授权按买断价的 2–3 倍一次性，或按授权客户数年抽成。前三类靠交付能力，最后一类靠产品化程度。刚起步时不要承诺“终身免费更新”，那等于把未来的成本提前锁死。

我现在的做法是：买断价含当前版本和 30 天售后，首年运维单独报，第二年起按合同额的 10%–15% 或按月计。客户不接受也没关系，至少他知道边界在哪，后面不会因为一次小改动翻旧账。

三种最容易亏钱的交付方式

只发源码不管部署。买家拿到压缩包，环境装不上、数据库连不上，最后申请退款。要么远程帮他部署，要么给一键脚本加 30 分钟录屏，并且把首次部署写进报价里，别送。

演示站拿不出手。求购区里反复出现的一句话是“必须要有演示”，还有人直接写“发演示账户，能看中，就会通知财务”。没有演示，买家没法判断你是不是拿别人的截图在卖自己的货。演示站不用多漂亮，但得能登录、能走完一条主流程、数据是干净的——演示账号降权，每晚定时重置数据快照。

什么都答应。“这个也能做”“那个加一点就行”，最后范围失控、交付延期、尾款收不到。合同后面附功能清单，清单外的需求一律走变更单，标价、标工期。

样本不是全量

买家原话照抄自 2026 年 10 月对互站网源码求购区的采集记录。原句按采集记录逐字抄，但帖子随时可能被删或改名，读者不一定能逐条回查。价格区间来自公开求购和同行报价的交叉观察，不同行业和复杂度差别很大，实际报价要按自己的交付成本校准。文中关于防传播的四层顺序，是我自己的判断，不是行业共识。

系列：上一篇 行业系统做成白牌，先看领域模型能不能复用 ｜ 下一篇 一个人做行业软件，先接单再做产品