直接服务器,前面套个 CDN 就行.

生态的话,没有 JAVA 丰富,但该有的基本都有.

云服务器大多禁止 SMTP,建议用第三方发信服务

上面书很全了,另外建议找几个好的开源项目,学习对方的源代码.
有空学学编译原理和计算机底层知识,对 C#语言的深入理解有帮助.

@minuo0day 对方这限制那限制,又不肯花钱,难了.

你这样,把所有的方案做个文档,提交给你的领导和对方,让他们选择.

@minuo0day 就算你不直接转成图片,你用其它的第三方的预览服务,也会转成类似图片的(放在临时目录里).所以说这个空间和流量你是省不了的.

如果不预先生成缓存起来,每次打开文件才去解析,然后通过某种方式(比如直接操作画布)显示出内容,那对服务器的 CPU 之类的压力也是承担不起的.

前端一直调用图片对流畅度造成困扰?这是什么意思?客户端每次不需要加载太多图片,一次要加载的前后几页,图片用 CDN 加速,做压缩.

安全吗,注意法律问题....
两都都可以实现任务,不过考虑到数量级,尽量用性能高一点的语言吧,所以推荐用 c#而不是 python

总结一:男怕入错行...

上面 5 个人 5 个答案....哎,LINUX 的桌面太杂了

好像不错,收藏了,试用中

@INCerry 你提到的这个 NanoFramework 有点意思,有空学习下

@INCerry 你说的是 NativeAOT 吧?那个我也很期待,等了七八年了

特殊运行时,感觉这些都太偏门了.以前学习用 go 做 wasm 的时候,发现有个 tinygo ,能生成更小的程序,但总有这样限制那样限制.所以我个人的观点是,如果可以选择,目前还是不要用.net 搞嵌入式的程序...除非没办法或者特别想用

1 所有源码编译一次
2 在新的测试环境搭建一次所有的模块
3 所有的文档过一遍
4 所有的源代码看一遍(至少每个文件打开看看)

@INCerry 楼主要讨论的适合不适合,而不是极限情况下能不能做.如果用.NET 什么都要都考虑各种细节,这样的用法应该是不推荐的.除非没有其它选择了.

我没有否认某些情况下"能运行" .NET 程序 ,但目前绝对不是嵌入式设备的好的选择.

比较好的实践,物理存储在数据库,并存一份在 REDIS 中

然后再加个配置更改以及订阅通知服务

简单的可以用 REDIS 来实现(可以订阅)

任何配置一更新,所有依赖配置的网站服务程序马上收到通知,并做出反应

内存极小的设备不要用带有 GC 的语言,特别是.NET 和 JAVA

有几个问题可以说明下:

1 独立打包出来 100K 是不可能的,那种情况应该是只编译了程序,没有带上运行时
2 现在.net 可以"自包容"打包,就是把运行时打包上去.我自己的项目因为相对大一点,未裁剪打包出来有 100M
3 现在.net 可以"自包容"打包成 linux 的"单文件程序",看起来像是 go 打包出来的程序一样,只是会大很多.
4 .net 打包时可以加参数进行"裁剪","裁剪"后文件会相对更小.但是目前这个技术不是很成熟,有些引用分析不到,造成不正确的"裁剪",导致可能上线运行会出错.
5 V2EX 前两天有个 GRPC 的性能测试报告,可以看出: .NET 写的程序性能接近甚至可能超过 RUST,但是占用的内存和 RUST 相对多一个数量级 179.23 MiB VS 18.35 MiB

如果路由器的存储空间足够,程序逻辑不大,或许可以勉强用.NET 写的程序,但真的比较勉强.这个问题不是"性能怎么样",而是"能不能跑"...

楼上说的纯 C#实现的 GRPC

https://www.v2ex.com/i/79Sn3u2v.jpeg

为什么要把.Net 转成 Java? 现在.Net 越来越好啊,感觉有点像 49 年投国军?