转赠看着是个小功能，实际是个立场问题：一张票到底属于下单的人，还是属于拿着码的人。立场没定，后面细节全在打架——允许转，实名核验形同虚设；不允许转，一个人替全家买票这种最常见的场景就过不去。

先分清三种模型

第一种是码即票，不登记使用人，谁拿着谁能进，最省事，也最容易被人二手转卖。第二种是绑定后不可转，下单收证件，核销比对使用人，转不动。第三种是中间路线，允许转一次，转过去之后受让人重新实名。我们接触的项目里做第三种最多：纯第二种在亲子和团队场景阻力大，纯第一种一到节假日就会被盯上。三种可以在同一套系统里共存，但每个票种只能选一种，选择要落在票种规则上，别做成全局开关。

还有一种现实要留意：很多游客并没有转赠的意识，只是把截图发到家庭群里。转赠功能一个字没开，票实际上已经在转了。这不是游客的问题，是配置没考虑这个习惯。

实名票转赠会不会破坏实名

取决于实名落在哪一层。如果实名只挂在下单人身上，转赠就等于让别人的证件号跟着一张票走，实名自然废了。合理的口径是让实名落在使用人上：转赠不是把票的状态改一下，而是一次身份重新采集，受让人提交自己的证件信息，原赠让人的记录仍留在流水里，两边带时间戳形成一条链。核销时比对的是当前持有人，系统里要保留转赠前持有人这个字段，出了纠纷能倒推这张票在谁手上待过。

一码多人是最容易被滥用的一类

领队一张码带几个人，现场确实快，风险也很直白：截图外传、码被复制、反复刷。要控住得三件事一起做：人数计数必须在服务端，一次刷码放行几人就扣几人，不能让通道设备自己判断还能不能放；二维码定时刷新，静态截图过了时限就失效；同一张码允许分批核销，但累计不能超过票面人头数。随行免票的人群要单记一类，否则带进来的孩子永远不在客流里。

入口位置也要一并定下来。转赠按钮只对已支付且未核销的订单出现，核销之后立刻收起；受让人必须登录才能领取，不能凭一个链接就把票取走。风控口径至少配两条：同一账号在短时间内连续出票并转出，标记出来供事后抽查；同一凭证被反复申请转赠，直接拦住。后台要能按凭证查整条链，赠让人、受让人、两个时间点一屏看全。这几件不做，转赠功能上线不到半年就会被做成固定的出货通道，到那时再收口，已经买票的游客跟着一起受影响。

次数怎么限，退款归谁

限制条件通常四条组合：每张票只许转一次、每个账号每天限几次、距开园多久之内停止转、转后不允许撤回。四条要一起配，只限次数不限时间窗，等于把最后一刻的倒手留了出来。最容易被忽略的是退款权：转出去之后谁有权退？默认应该留在原购买人手上，否则转的人还能把款退回来，这条路会被做成套现。受让人只能申请、不能自行退，退款原路回到支付账户，发票归属同理随购买人走。

要不要开这个口子

决定前先把两条讲清楚：这张票是不是稀缺资源，稀缺票开了就等于给别人做免费倒手的通道；现场有没有能力处理"码是我的但证件不是我的"这类争执。答案不确定时，先在亲子票、双人票这类低风险票种上试，把转赠流水单独出一张表看两周，再决定要不要铺到主力票种上。