大概 2014 年左右，我住在广州棠下，自己去办理的电信宽带（ 20M ），网线外挂到我窗口，第二天网线就直接被剪了，找电信的人，师傅直接告诉我，这种情况一般都是房东搞的鬼（城中村自建楼梯房，一共 8 楼，一楼 3 户，我住在顶楼），师傅接好以后，后来就没有出现什么问题了。用了 3 个月左右，城中村开始线路改造，所有的电信宽带都不能用了（电改光），电信就把钱退给我了，没记错的话当时 4G 还没有普及，我就在公司里面下载电视剧，然后回家看。后来玩了一下无线破解的东西，蹭了邻居的 WiFi （城中村到处都是 WiFi 信号）一直用到 2016 年离开广州。

现在想想，如果当时就有 4G 或者 5G 的话，我肯定也不会去办理宽带的，当然每个人情况不同，我也不刷短视频，仅仅只是浏览一些新闻或者电子资讯网站。

https://i.imgur.com/gnUAwAv.png 挺有意思，就是操作稍微有点卡顿

@jazzg62
@Vegetable
@kitkat
这两天相比一周前已经大有好转了，如果持续恶化，我肯定还是要去医院做个全方位的检查的。

我深有同感。前两周，我突然开始喉咙痛，除了这个也没什么其他症状。喉咙痛持续了两天后，就一直咳嗽到现在。每次咳嗽时总感觉肺里有痰，却怎么也咳不出来。现在我已经不敢用力咳了，一使劲咳，痰里就会混着一点血沫。

等额本金 = 每月还款本金固定 + 利息按剩余本金计算 → 每月还款逐月减少，总利息较少 + 前期月供高 + 后期轻松

等额本息 = 每月还款总额固定 + 利息按剩余本金计算 → 前期利息多本金少，后期本金多利息少，总利息略高 + 月供固定 + 预算更稳

不应该是高利率的时候考虑提前还吗，降了利率为什么反而要提前还呢？

感谢，已领取

谢谢你，3 个 5-2

已领 5 元，谢谢

硬盘应该是最好的选择，云存储是按照容量固定周期扣费的，比如 1 个月 1 毛钱 1G ，那么每个月都要为此付费，你在本地跑的话，其实用云服务既无必要也不划算，而且大多云存储上传下载会有额外的流量成本。

微服务不等于微服务框架。微服务只是一种架构风格，一种设计原则，或者一种部署策略，这两个东西虽然处在不同的层级，但是二者是正交的。为了实现微服务架构，不一定要使用微服务框架，但框架能让微服务更易落地。反过来说，使用了这些微服务框架开发的应用，也不一定能够实现微服务架构。

如果了解 service mesh 并使用容器，可以在不引入任何框架的情况下就能实现微服务这种设计理念。或者换句话说，开发者可以在不使用任何“微服务框架”的情况下，就能获得“微服务”的那些好处。毕竟微服务从一开始倡导的就是足够小、足够自治、灵活选择，支持跨语言、跨平台。

像 kratos 或者 java 中 spring cloud 这种“云原生”微服务框架可以在没有容器环境的情况下，也就是没有 sidecar 代理支持的情况下，直接把微服务需要的那些组件编译/打包进应用程序，在应用层内置微服务那些组件的功能。

因此，部分企业会直接使用 service mesh 作为基础架构，同时使用微服务框架来简化开发。最终，是否使用框架、使用哪种框架，取决于自身的架构需求和技术选型。关键是要明确：哪些能力应该由框架提供，哪些可以交给基础设施，从而找到最合适的微服务落地方式。

我的飞利浦用了 10 年，现在还在服役

这种直接预先建立索引，ES 不是万能的。

五金还要两三万块钱

我来给你把问题好好梳理组织一下：

因工作需求需要用到快递单打印机，但因硬件为 Mac mini 且仅能安装 ARM 版 Windows ，导致无法安装快递单打印机驱动，现通过服务器安装 AirPrint 服务并共享给 ARM Windows 使用，虽能打印，但无法自定义纸张，导致打印比例不正确。

mongodb 从 5.0 开始支持时间序列（ Time Series ），可以提高查询速度。

https://www.mongodb.com/docs/manual/core/timeseries/timeseries-procedures/

继续上班等下次发工资，如果不给你全额发的话，发《被迫解除劳动合同通知书》，然后仲裁。

一种基于邮箱的用户付费系统构想 ❌

一种限制设备激活数量的方法 ✔

就你贴出的这个例子而言，是的，DbContext 永远只会创建一次。

但是这种做法是有问题的，仅就这个例子而言，DbContext 不是线程安全的，这意味着当多个线程同时操作一个 DbContext 对象可能会引发数据竞争问题，破坏其内部状态的一致性。

微软官网是这样描述 DbContext 的生命周期的：The lifetime of a DbContext begins when the instance is created and ends when the instance is disposed. A DbContext instance is designed to be used for a single unit-of-work. This means that the lifetime of a DbContext instance is usually very short.

工作单元模式简单的来讲可以理解为对应于数据库的一个事务范围，在这个事务范围进行的操作会被追踪然后被提交。除非你确实有理由要一直保持一个 DbContext 的实例，并且考虑了线程安全问题，那么这么做就没什么问题。