不是我说 ... 不叫 PAL 的仙剑都是没有灵魂的 ... 这 Sword & Fairy 是个啥鬼 ...

哪有 Fairy ... 谁是 Fairy ... 整个仙一里能跟 Fairy 勉强沾边的就只有彩依了吧 ...

以及不太明白为什么上 SDLPAL ... 感觉更像个玩票的项目 ... 而且真的不会有版权问题吗 ...

如果真是官方想做 ... 直接用新仙的壳套仙一的文本一字不改再补个要改出来的结局 ... 绝对好评如潮 ...

@Muninn 事实上不用节约的 ... 在我的测试里 ... 最多回复五条指的是「五条内容不一样的消息」 ...

连续且内容相同的消息可以疯狂回复 ... 不受这个限制 ...

再者说所有消息都有五条额度 ... 我可以随便发个不在命令列表里的消息 ... 接下来坐等收消息就好 ...

其实不需要为了这个功能改动太多 ... 只需要一个可以产生消息且不将任务标记完成的动作就好 ...

或者一个更简单的办法 ... 保留现在 bug 中的 fail / succeed 但改个消息内容改个名字 ... 就齐了 ...

@Muninn 因为实际上同样的东西我好几年前就琢磨着要做来着 ... 但因为舍不得三百块一直就没做 ...

所以这些设计其实一直在我脑子里 ... 我甚至考虑了有用户量之后疯狂推广告养自己的可能性一类的 ...

跑题了 ... 关于 proceed 我想要实现的功能是针对一个任务可以推送多条文字消息 ... 和被取走还不太一样 ...

现在如果我取了不做或压根不取会产生自动超时 ... 而 proceed 状态实际上就是 cancel 掉这个超时 ...

说到底我想要实现的效果是可以不受模板消息六十分钟五条的限制给自己推送多条文本消息 ...

和现在 bug 中的 fail / succeed 行为类似 ... 即如果我有一个已被拉取处理状态标记为 proceed 的任务 ...

那么我在后续比较长一段时间里 ... 可以一直用同一个 job id 给自己发消息 ... 直到该任务标记完成为止 ...

rate limit 这事情 ... 实际上是个「要不要为了可能存在的恶意用户增大所有人消耗」的问题 ...

我觉得可以先不做 ... 如果真的有人不以测试为目的高并发压机器的话再说 ... 感觉上应该不会 ...

至于离线任务 ... 现在的在线状态其实只能保证一分钟内 Agent 活过 ... 之后会不会取其实是不可控的 ...

而且如果对任务的时效性没有要求 ... 我大可以把一分钟拉一次改成三分钟拉一次 ... 避免超时还降低机器压力 ...

细想了想这种场景是存在的 ... 但如果要改的话涉及还挺多的 ... 对我而言不是刚需 ... 还是看你的计划啦 ...

@Muninn 其实微信的聊天窗口就是个简陋的 log ... 如果要做详细 ... 可以考虑比如只保留最近三个月 ...

但保留归保留 ... 「已完成」的状态还是不能更改的 ... 如果对已完成的任务执行 fail / succeed 可返 405 ...

同时强烈建议引入 proceed 态用于耗时操作的反馈 ... 否则现在只能调 /message/info 感觉不太对 ...

至于 info 和 warning 是我的问题了 ... 我是老版本微信 ... 包括 message 在内三种模板显示都没区别 ...

另发现的公号 bug ... plan 里面已有 agent 和最大 agent 数量显示颠倒了 ...

以及「每分钟最多发起一次查询」这句话感觉也有哪里不太对 ... 一来实测并没有这个限制 ...

二来这不是「最多」而是「必须」 ... 如果我不每分钟发起一次查询的话会离线的 ...

说到这个 ... 离线则不吃任务这事儿也怪怪的 ... 如果是我我会设计成离线状态吃且仅吃一个任务 ...

离线状态无未拉取任务正常提示等待拉取 ... 如果有未拉取任务则提示队列非空之类的 ... 不过这都是后话了 ...

玩了半天 ... 很有趣 ... 比 ServerChan 更简单实用 ... 希望能坚持下去 ...

另外一些问题 ... 一是我同一个 job id 可以 fail 或 succeed 无数次 ... 这是有意设计为之的还是个 bug ..?

我感觉可以加个 proceed 作为中间态 ... 一旦到 fail 或 succeed 感觉 job 就能删了 ... 不然留着有啥用 ..?

另外 ... 两个消息通知接口 /agent/info 和 /agent/warning ... 显示的消息好像没区别 ... 那为啥分开咧 ..?

@paowang 我看了一遍代码没问题 ... 能走到「通讯成功」那一行道理上说一定是更新成功了的 ...

如果你确定你没看错数据库以及没看错行 ... 你看到的就是实时的数据而这个数据确实是没更新 ...

试试把这一段里涉及事务的部分注释掉再跑看看 ...

从你发的这段代码里 ... 我看到你启动了事务却没看到提交 ... 看到存了几个变量却没看到在哪儿用到 ...

所以具体逻辑我也不确定 ... 但按你的描述 ... 如果你确定「部分 zh 更新不进去 部分就可以」且无报错 ...

那么我猜测代码逻辑应该是没啥问题 ... 没有更新的原因大概率是你提交的 zh 和 sbm 不对应 ...

查一下库看 y_zh=e3 的时候 y_ssrj 是多少 ... 把 y_ssrj 的值写在表单 sbm 里和 zh 一起提交应该就好了 ...

在纯 HTML 的层面如果不增加 tr 肯定是做不到 ... 只能用点别的技巧如下 ...

i.imgur.com/VjSEdVS.png

原理是这样 ... 把新增的 td 移出文档流单独显示 ... 然后增高 td 给新增的 td 腾位子避免挤在一起 ...

能实现但挺 ugly 的 ... 如果系统只限制了 tr 的数量 ... 按楼上说的用 div 模拟 table 应该是个漂亮些的解决方案 ...

@CallmeDredd 多谢提醒 ... 我这台机器 150 三年 ... 免费升级只能升到 125 ... 升不了 246 啦 ...

我也有台企鹅 125 ... 443 空挂着 ... 一天到晚的全是这种玩意 ...

i.imgur.com/NU0rZzX.png

我是准备哪天无聊了专门写个针对 phpunit 的反馈 ... 看看这 bot 下一步想干嘛 ...

如果你不想 bot 过来晃悠的话 ... 反正有 IP ... 来一个 ban 一个来两个 ban 一双早晚能清净的 ...

首先说结果 ... php 和 go 显然是两个方向 ... 应用场景和功能定位都完全不同 ...

中型以上的 Web 项目对我来说使用 php 还是首选 ... 小型项目里 Go 的二进制包即传即用实在是深得我心 ...

真的 ... 语言间没有说谁是替代谁的一说 ... 各有各用 ... 多会一门语言多一条路罢了 ...

题外话 ... 我有台 32MB 内存的 VPS ... 跑了个自制的 Linux ... 只有 kernel + rootfs + Go binary ...

整个系统里没有任何我用不到的文件 ... 整洁精致 ... 而且服务跑起来内存占用稳定在 8M 上下 ...

就这个效果 ... 换其他语言 ... C 系列不论 ... 不管是 P 开头 R 开头还是 J 开头的都实现不了 ...

这时候我用 Go 写是因为我不得不用 ... 总比折腾内存强 ... 其他场景自然有其他的需求 ... 再按需选语言就好 ...