@lujiaosama 这个和你使用什么技术没啥关系, 主要是微信不允许你为使用你服务的 Tenant 代收款项到单个账号. 而是需要你的租户单独注册账号, 汇款总是是不走你们公司的银行账号的.

你说的这些和 ES 这门语言没啥关系. ES 的标准库太弱了, 前端看上去如此繁荣的主要原因就是因为标准库太弱, 而 JS 要做的事情又越来越多, 因此大家不停的造出来各种轮子, 然后有了 npm 这种辣鸡, 然后不停的玩废掉一个个框架, 再来创建一个新的. 核心原因就是标准库太弱了, 随便实现点什么功能都要引用一大堆第三方 library, 而且很多 Library 就几行代码, 你根本不知道整个 npm 按照的依赖都是些什么鬼东西.

按照标题检索过滤本质上并不是什么逻辑操作, 也不属于业务流程, 简单来说, 它就是个数据检索, 正常情况应该由 Repository 这种基础设施提供好封装, 对业务层次完全透明. 另外 XML 是什么鬼? Java 的 XML 配置生成 SQL?
另外什么叫将业务写入 SQL? 查询当然最终是需要写入 SQL 的, 不管你怎么做. 将业务写入 SQL 一般说的是再 SQL 层面做一致性逻辑校验, 属于修改范畴.

人力是有限的, 状态管理是困难的, 所以我们有了方法执行的上下文, 并限制了在上下文上可执行的操作, 因此有了对象. 你当然可以彻底抛弃对象, 然后将 class 作为 namespace. 那我什么不选择 C 语言呢?

@ecloud 配相对地址, 前端和后端部署在一起

意思就是 Class 文件作为规范支持的很多功能在 Java 语言层面是没有公开的.
如果有其它语言编译到字节码 Class, 可用选择公开这个特性.
或者你也可以后动使用字节码写代码, 这样就可以用到 Class 公开的任何特性了, 但我想一般人不会这么干.

@错人了, 不好意思 @leexy , 本来是要 @kklk

@a33291 哈哈说的是实话. 其它语言的语法糖都它弱了. C#的核心问题还是在生态上. python 的性能实在太差, 除非用来做胶水, 它的性能属于放弃治疗的. 我天天写 python/ts, 越写越爽.

@leexy 另外 V2EX 这个平台我感觉并不适合文这个问题. 因为这个问题网上已经有了无数的答案, 知乎上这个问题我都看过好多次了,善用搜索引擎. 我怀疑你在水铜币😄😄😄. 我也是闲的无聊...

@kklk 工资和任何语言都没有太大的直接关系, 任何一门语言中都有高收入的, 只是有一个大致分布.
工资高的大部分职位要求的不是语言. 而是解决问题的综合能力.
作为职业程序员, 你至少需要会 2-4 门编程语言,
工业界广泛使用的这些语言: c/c++/rust, golang/c#/java, javascript/typescript, python/R, 你都可以学一学.
他们都有自己的生态位, 在自己的生态位上, 这些语言相比于其它语言有自己优势, 如果一定说哪一门必须学, 我推荐 JavaScript, 所以你首先要知道, 你未来主要想要从事什么样的工作, 它需要的技能树中那个语言是必须的, 就先去学它.
软件从来都不直接受到编程语言的限制. 但各个编程语言都有自己的习俗和看待并解决问题的思维.
多换几个语言, 可以看看从不同角度解决同一个问题时候的思维差异.
想要踏实将软件工程师作为职业, 最需要是牢固掌握考研的哪几门计算机核心课程, 然后选择自己喜欢的而且认为有钱途的方向深耕. 另外工作久了, 你会发现技术并不值钱, 值钱的是业务逻辑和商业模式.

@kklk 另外你需要找个事情来做, 例如使用 Span 写个性能不错的 JSON 解析器. 这种纯粹不需要依赖第三方的 API 的库, 可用考验你对语言的理解, 还有抽象问题的能力. 编程的核心是使用某个语言去抽象某种需求, 然后平衡各种矛盾. 如果你遇到学习问题, 我可以给你提供免费咨询.

@aw2350 人家学什么, 关你毛事! @kklk 它就是说 @aw2350 , C# in Depth(深入理解 C#), Essential C#(C#本质论), 另外微软提供的文档非常完善. 作为一门语言的 C#, 发展到 11 版本, 已经非常完善, .NET 6.X 的性能也绝对不差. 如果你不认为微软有原罪, 完全可用认证学. 另外 C#和 TypeScript 是同一个人建立的. 有很多相似性. 另外如果你需要找工作, 的确需要仔细思考, 国内.NET 的工资偏低, Java 系的很多人掌握了互联网的话语权, 微软自己又作死, 开源太晚!

@aglsv 你审查过 HTML 的实时元素吗? 我刚刚写了测试了一下, 完全没问题啊. 这个原理上来说, 和后端都应该没啥关系.

@aglsv 正常情况, 这 2 种写法, 浏览器应该发起的都是同一个路径, 也就是:protocol://host:port/$index_html_path/static/js/app.e6cc3797.js, 服务器收到的请求地址应该是同一个才对

@aglsv 没有抓不到一说, 你在浏览器的调试控制台看下, 它实际的请求路径是什么, 服务器不知道有相对路径这回事. 你看下浏览器实际发起请求的完整 URL 地址. 服务器发起的地址都是绝对地址, 找不到应该返回 404 或者其它重定向.

@aglsv 你的服务器是怎么配置的, 正常情况下: static/main.js 和./static/main.js 应该是一样的, 而使用域名+statc, 应该是必须写成 /static/main.js

@novolunt 你和我们说的不是一个东西, 而且根本不是解决问题的办法

@churchill 你这个说法, 我严重不同意, 针对互联网项目, 这样搞的确不大合适. 但政企很多项目, 在客户端直接好维护的多. 完全不需要搭建一套后端找人长期维护.

浏览器是没法解析 rtsp 的, 我目前用的是 hls 的流, 延迟 1-3s, 用的 H265, 在浏览器上使用 ffmpeg 的 wasm 解码 H265, 大部分浏览器都不支持直接播放 H265.