@unclemcz 不管在那里都输入车牌缴费反而没什么问题, 但是有的人就是喜欢在杆子底下缴费出去 , 操作的还慢, 会导致出口堵.

现在其实两种方式都提供, 你可扫场内码预交费, 也可到出口免输入车牌直接缴费,

问题出在免输入车牌直接缴费这里, 有年龄大的人, 认为扫了就能缴费什么都不管...
抢缴费这个问题其实是越来越少的 (码的位置调整让后车更难扫, 知道不能扫前车的人越来越多....)
可能后面更少了, 也会转成自动退款模式, 或者每个停车场可配的可选自动退款或手动退款

@Jtyczc 同一个车牌付了两次费 , 再次拍本来就是对的,
并且车子拱到杆子底下的时候, 现在的主流方式其实已经拍不到车牌了 刚才 @错了

@unclemcz 见楼上

@Jtyczc
其实 3 种都有用到,

是很难错, 但是总有些奇葩的人

第一二种其实是差不多的
"第一种需要排队" 后面的人真的会在前车还没出场时就扫码, 还有就是主驾驶和副驾驶同时抢着缴费的

"液晶屏幕展示可变二维码, 强光下或者太小会有很多扫不出来的", 很多地方出口也会贴固定码,

可以总结下: 后面的人真的会在前车还没出场时就扫码, 这个偶尔真有人干

是很难支付错误, 但是量大了 就是有人抢别人的码, 就是有人不看车的照片和车牌, 直接缴费....

@unclemcz 是 trade_no 和 order_id 形式,

单人多次付款自动退款是没啥问题

同时两个人付款, 总是会存在一个钱退给谁的问题. 如果不管是退给谁都无所谓那就自动退款也没啥问题,

同时两个人付款 如果只能退给错缴的人, 自动退款就 "失灵" 了, 如何判断谁才是错缴的? 感觉简直无解

这个场景其实就是汽车缴费出场, 扫码直接付款
错缴费的人 A 实际需要缴费的人 B, A 和 B 同时缴 B 的车牌的费用

先收到了 A 的回调, B 的回调比较晚, 然后如果退了 B 的, A 就会投诉过来(A, B 互相不认识没有关系),
因为 B 相当没有收费逃单了, A 缴纳了 B 的钱, 自己的又要付.

电商那种思路的话之间退掉多付的就好了没啥问题,不存在一个 trade_no 退掉了多缴费的还有啥纠纷, 一般没有陌生人帮你付订单的, 并且就算给你退错款了, 也可以取消订单不给你发货这种手段

汽车缴费到业务结束流程太快了, 最快的话付完钱 10 秒内就溜了, 退错了就没有什么补救手段都没有了,

多次支付无法规避

楼上说的自动退款也是个办法!

但是我这里自动退款也不行,是扫码缴费, 存在错缴费的人先缴费的情况, 自动退款可能退错.

目前是手动等客户联系退款的, 页面上各种提示和信息展示, 实际场景优化, 还是有人两个人客气抢着缴费同时缴纳, 或者排队的时候后面的人错缴前面人的, 现在的多次缴费比例大概是 10 万分之一吧, 勉强接受

尝试过 RESTFull, 但是没有完全遵守起来, 现在个人的实践,
http code 500 服务器真的内部错误.
http code 401 未授权
http code 200 (业务 code 400 是密码错误这种), 就是业务上的错误,我认为是成功的, 让让前端会有个统一的拦截器去处理业务 code

原则就是 http code 必须保证符合原有的意思, 200 里面再加上业务 code,
但是像是未授权这种, 可能既是业务错误, 也可以理解为 http code 错误 就很头疼

RESTFull 我遇到的问题(Java):
1. 有些内网的防火墙不允许 delete 这种请求进去.. 很让人无语
2. RESTFull 一个 URL 可能对应多个接口, 按照路径配置各种规则的时候 , 日志打印, 就打地址的话看不出调用是那个具体接口, 解决其实也能解决, 日志加上请求的方式, 规则按请求方式 + URL 去配置.
3. 就是理解不明确的, 不知道定义为那种方式的接口
4. Get 传大量查询参数, 不方便的接口, 前端意见很大, 后端接收也不是很方便, 偷懒用 Post 了不少

我觉得 Get 传参限制太多了, 通常只能携带路径参数 (其实理论上服务器也能接收 Get 请求体), 要是能加一种查询的
类似 Get + 能发请求体就好了, 其他的问题都是可以解决,最多麻烦点, 慢慢都会好

@cpstar
是的, 这个卡比较低端, 但是显存有 4G, 渲染方式的不同 结果会体现在 GPU 核心的使用占用率上吧?

@kokutou 感谢! 测试结果 , 4 个电视调整成,1080p 正常了, 应该像素填充率问题
一个 4k 屏幕 800 万像素, 卡最高支持 1800 万每秒, 我去采购新的卡了

@kokutou 像素填充率, 可能是这个 我去试试, 卡的是 18.93 GPixel/s, 4 个屏幕全是 4k 的, 监控可有 25 帧的, 简单算了下刚好两个屏幕的时候会满

我不太理解瓶颈在哪里, 显存? 显存带宽? 很想知道原因..

还有个 《生于苏联》 也不错

大概和你差不多的水平, 工作 3 年了, 正在新概念英语 + 扇贝单词 这种东西滴水穿石吧 急不得.

学起来很快的.. 用了大概 2 天换过来的, 壁纸换成键位图, 那个忘了去找那个.

前提是 先练习记下大概位置. 我用的 在线双拼练习记键位的 大概几个小时就差不多了
https://api.ihint.me/shuang/

#20 说的好, 不然你的风险就是所有使用者的总和

@Michelangelono DDNS 对网络有要求的, 必然我在的江苏电信 你很容易要到动态 IP, 移动就不一定了, DDNS 对车场网络有一定要求的, 财大气粗当然都没所谓, 有的甲方甚至自己有 IP, DDNS 实现也很成熟了, 基本不用开发. 我们还是用长链接的形式, 这样车场只要能上外网就行

工控机指的是铁壳子电脑小电脑嘛? 这种就是迷你笔记本, 配置蛮落后的, 我们也主要用这个, 因为我是做 Java 的我也不用管工控机, 但是我自己也是 DIY 玩家.. 我觉得这种铁壳子小电脑也没好到那里去.... 质量还是性价比. 就是普通电脑级别的

我们体量小, 工控机买的也很杂, 因为工控机没什么技术含量, 用的好多年前的 CPU 和硬件.... 各个牌子都用

相机也会提供动态库接口 , Java 去调用也可以.. 我两种都实现过, 动态库毕竟提供的接口比较少嘛. TCP 是一体机相机最全的接口了

我是做这个的, 相机(一体机) + 道闸 + 屏卡 + 摄像头监控 , 线上支付平台等等..

相机都是由 TCP 协议支持的, Java 可以做(网络编程这块 用 Netty Mina 都行).
道闸的开闸信息是可以通过相机透传的, 就是闸接到相机上, 屏卡也是 TCP 的一般各种私有协议, 这边也是用 Netty 做的.

相机也可以透传屏卡的信息给屏卡, 屏卡接到相机上.

硬件上总结: 基本都可以用 Java 实现, 岗亭软件用 Java 做的话就是网页端了, 做的最大的科拓(速停车) 也是用 Java 做的
如果车场做桌面端 那就基本上要 C++实现了, 也有不少厂家这么做

线上和车场交互: TCP 长连接, 车场注册到服务端.

线上部分总结: Java 最合适, 支付或者各种线上的信息 命令下发, Sokect 服务端, 肯定 Java 做最合适

普通的摄像头监控: 这个牵扯到存储, 网络带宽等等各种问题, 一般车场本地存 3 个月就拉倒把.. 不然处理很麻烦

自己用 Filter 链 实现一个授权, 很简单的, 能完成登录和当前线程获得登录的用户信息就行.