awanganddong

小说这种，txt 文件就可以了。毕竟发布之后是很少修改的。然后把对应的文件名存数据库就可以。

小说 id/章节 id

找到问题了，我在中途有个其他 update 操作，把用户余额还原了。

@xiaofan2 没有校验 update 返回值。做的类似这样的操作
Db::transaction(function () {

//用户账号
$money = 10000;
$accountModel = new Account();
$accountModel->where('uid', 0)
->update([
'dream_fund' => $money,
]);

$billData = [
'uid' => 0,
'money' => 0,
'itime' => time(),
'utime' => time(),
];
$this->model->data($billData);
$this->model->save();
});

@realpg 你这适合出本书，讲讲国内购票系统的发展史。

@234ygg 根据 realpg 讲的业务迭代路线，就是你讲的这种技术方案。

@realpg 你还是别写了，不然我觉得你过不好年。

@realpg 如果根据这种历史业务来走的话，那么 12306 就完全可以基于历史的用户购片信息，对各个站点分配不同的票量。当然这里边肯定存在不同操作对同一张票的 争抢。这个 12306 最开始用的这个技术 GemFire 。下边是链接地址： https://www.51cto.com/article/501374.html 后边用国产自研替换了。

@alanerzhao 网站还是很不错的。
比如我想要写一个 app ，首先找同类型的产品，把每一张界面截出来。
然后 ui 工具直接进行调教到合适的样式，然后直接转成 html 输出。
最后把 html 转化成对应客户端代码，基本上只需要微调。

初期的话，肯定是以最小的代价来快速的验证商业模式，而这些 ai 插件提供了不错的选择。
这周就把我一个小程序重构了下，直接把 figma 文件导入，然后自动生成小程序前端代码，我微调下搞定。