include 头文件即可实现外部库的引入。不过你要搞清楚这个库到底是 C++ 库还是 C 库。
如果是 C++的，那么请将你的编译器保持在跟其库一样的版本，否则请自求多福

@yazinnnn 受 ML 系的影响更大，里面一堆函数的用法。对类型系统的推崇

@Lemeng windows 10 也有沙盒，不过那是属于高级功能，家庭版本不带。专业版直接快速开一个虚拟机，如果你觉得隐私很重要，完全可以用这个功能

@skypyb avif 都是 chrome 一家在支持，更加不要说 heif 了
当然你是做客户端的，自己实现支持的话，那么这服务也不见得没用

人家二维码扫码不是这样做的，你开三个接口去做吧。
1. 接口返回二维码
2. 提供一个轮训接口，然后前端轮训对应的接口就知道有没有扫描了，扫描之后结果怎么样
3. 回调接口，接收回调的请求
这样一整套下来，你就回到最基本的用 flask 写接口的流程上面。看你的问题，你根本就不了解 wsgi 跟 asyncio 那套东西的运行机制，及早回头吧

@zyb201314 有两种可能，一种是一个单词很长，你还没读完（截断了），第二种是你有可能读到单词最末尾的字符（刚刚好），两种情况都需要再读数据再解析

自己写一个简单 parser 不就可以了？实际上内存使用量可以是一个最大单词长度的两倍（动态扩展）
这个问题不是跟处理 TCP 流一样吗？
你只要读一定量的数据进你分配的缓冲区（预分配），然后开始解析。
1.如果整个缓冲区都读完了但是还是未能解析出一个单词（ token ）那么就将缓冲区变为已有的两倍，继续读取内容并重复此步骤。
2.如果解析到缓冲区末端，但是不是结束符（我假定是空格符），那么就继续读取你缓冲区长度减去未解析字符长度的字符。
然后继续上面的流程，进行解析。但是有直到读到文件底部就可以了。

@jinliming2 哦，你不说我都没搞懂，的确是这样

uWSGI 跟 gunicorn 都很成熟的方案

uWSGI 主要是用 C 写的，一来效率高，二来它自带很多功能，比如集群管理，还有进程管理啥的。单单用它就可以实现其他 wsgi 服务器+进程管理器的效果。还有一点就是它跟 nginx 结合比较好，nginx 跟它通讯是二进制的 uwsgi 协议(他们自己都吐槽取了一个坏协议名)，理论上会比 gunicorn 跟 nginx 之间通讯高效

gunicorn 也是一个很高效的 wsgi 服务器，一来它很容易配置，二来它还有很多 worker 可以进一步压榨性能，当然了，它自身的性能也不差。同时它还能通过跟 uvicorn 结合，作为一个可以用于生产环境的 asgi 服务器。

@dimlau 是不是示例代码漏了一些？我好像没看到有"}"插入进去
按我的理解，如果仅仅是字符串拼接，不涉及到序列化与反序列化，各种库底层修改的逻辑应该大同小异。最多可能会比你这个高效那么一点，区别应该不大。仅仅是 API 封装了，可能好看一点罢了。
有的封装还有可能有额外的开销。看你的选择

@programV2 直接传到块存储，然后重新开一个实例再把数据挂载上去不行么？

@kaka6 在线转码跟你用软件转码是一样的，绝大多数都是调用 FFmpeg，有啥区别。最多就是转码参数有差异。要多干活才是真的

我就提一个吧，你们都是跑在物理机上面吗？要不然还是按 @liuch 的说，根据统计模型来调吧。
书本上的东西很理想化的。虚拟机的 CPU 调度就能将所谓的最优碾烂。

内存跟数据结构没有什么关系
当然你粗略地理解存储引擎在处理数据的时候是会序列化与反序列，这并没有什么问题。
像 C 那样能直接操作内存的语言，字节就是数据结构，取决你如何“解释”而已

@airqj 可能涉及到驱动吧，毕竟硬件产品

@Mithril 高负载下面可能会出现，之前有遇到维护的服务器各种内核问题，RH 系的，内核相对稳一点。
如果自己公司有内核维护团队，那么区别应该不大

@monetto 君子协议，不过话说他们是有中国区的销售的。你们公司大一点的话，通过遥感技术，应该会上面推销或者法务发邮件

你们这些公司都没有流程，都是一个说了算的吗？
出了问题，当然是牵涉到整个流程的人都要背锅。哪有最后干活的人一个人全背锅的道理。
当然了，如果后果太严重了，那么当然还是会干掉一些人来祭天。这也很正常。

@WebKit 用我的老 MBP 就是感觉一种轻微的卡顿。新的台式机倒是很快。如果笔记本要有良好的输入体验，我大概会选择最简单的脑补