@byqtxdy07 #5 我们用的也是 proto3 啊，optional 标记的字段就有 has 相关属性。。你这啥毛病

https://protobuf.dev/programming-guides/field_presence/

你看这个文档，按文档中的意思，V2 版本并不需要标记为 optional 就有 has 方法，V3 只有标记为 optional 的才有 has 方法，这好像和有些搜索结果说的不一样啊

怎么记得 QK 好像是矩阵乘法，也就是点乘，哪里来的 Q 第一维度只和 K 的第一维度产生作用，就不符合点乘规则吧，和后面 V 才是普通乘法才有你说的这个问题吧，你从哪找的这个公式都看不出是点乘还是普通乘法了

生成的结构还有个 hasTitle 的属性吧，你看看，客户端不给 title 赋值的时候服务端接收解码这个属性返回的就是 false ，null 值不标准，需要额外信息传递不说可能有的语言无法正确处理 null 语义

这数据量如果客户端安装不能保证内存充足和 ssd ，估计换 mysql 也提升不了多少，不知道你的客户端安装环境怎样，ToB 的话其实客户端大个几百兆无所谓，ToC 的话安装环境估计也无法保证资源充足似乎你换啥都意义不大吧

乱发 GPS 信号违法吧，无线电不能完全限定范围，要是旁边恰好有机场军事基地什么的，够你进去呆好久了吧而且保证办事效率高高的

电压不足你这空开估计是坏了，不过房间线路漏电也可能会电压低，空开似乎只有短路或者电流超过额定电流才会跳，不接漏保的话房间线路漏电看不出来吧，最好还是换掉那个空开，五金店都有卖，家用一般 16A 够用了

空开有标额定电流也就是额定功率，不超过都可以接，这几百瓦的不用担心吧，空开分路接只是为了可以单独开关方便吧，漏保才有防触电漏电的功能吧

好奇这套多少币？

微秒级和纳秒级，如果一个语言标准库 hash 表才有读 redis 的速度，那这语言太废了，没有 4 个数量级的差距说不定都是你用的有问题

@hero1874 我是在手机上安装了 gps 记录器给 hss 提交经纬度记录，然后 hss 在地图位置那建个位置圈一个半径 3 公里的范围，手机进去这个位置就是到家附近就好了，gps 记录器 5 分钟提交一次并且设置读取位置超时 2 秒也并不耗电，灵敏度也够了

@shaunn #5 其实我就是搞了个 hss 的自定义组件写了算法来依据室内外温度湿度和风速来计算体感温度，然后再通过这个算出来的体感温度通过 hss 的自动化来控制空调，自动化里又添加了时间和是否在家、是否即将到家等其它条件再开关空调且设定不同温度

https://github.com/snower/homeassistant/tree/main/custom_components/apparent_temperature

算体感温度的算法就是这个

sensor:
- platform: apparent_temperature
name: "室内体感温度"
unique_id: "sensor.shi_nei_ti_gan_wen_du"
temperature_sensor: "sensor.v1_cloud_9ad320_temperature"
humidity_sensor: "sensor.v1_cloud_9ad320_humidity"
outdoor_temperature_sensor: "sensor.v1_cloud_bfa384_temperature"
outdoor_humidity_sensor: "sensor.v1_cloud_bfa384_humidity"
indoor_wind_speed: "0.2"
humidity_role_coefficient: "0.2"

- platform: apparent_temperature
name: "室外体感温度"
unique_id: "sensor.shi_wai_ti_gan_wen_du"
weather_sensor: "weather.wo_de_jia"
temperature_sensor: "sensor.v1_cloud_bfa384_temperature"
humidity_sensor: "sensor.v1_cloud_bfa384_humidity"
outdoor_wind_resistance: "0.6"
temperature_convection_coefficient: "0.24"
humidity_role_coefficient: "1.0"

配置文件设置了两个 sensor ，室内体感温度和室外体感温度

参数：
weather_sensor #天气传感器实体 ID
temperature_sensor #室内温度传感器实体 ID
humidity_sensor #室内湿度传感器实体 ID
outdoor_temperature_sensor #室外温度传感器实体 ID
outdoor_humidity_sensor #室外湿度传感器实体 ID
indoor_wind_speed #室内风速
outdoor_wind_resistance #室外风阻系数
humidity_role_coefficient #室内湿度影响系数
temperature_convection_coefficient #温度对流系数
humidity_convection_coefficient #湿度对流系数

本身来说还是看室内外温差、天气对流和辐射因素会体感温度会有明显差距，天气晴朗白天室外 10 度室内 18 度感觉都热了，凌晨室外 10 度室内 18 度估计你都感觉冷死，省电来源看起来是来自体感暖和就很快关闭空调

我就是用空调伴侣，外加米家温湿度计，室内室外各放了一个，然后用 hss 搞了个自定义算法依据室内室外温度、天气情况、是否在家、是否快到家和不同时间段自动开关空调来调节温度和湿度，一般设定晚上健身、睡前和起床前后略微提高温度，舒适度不说重点是按月下来发现比单纯用空调还要省电不少😅😅

那不就是取消桥接模式么，你在说啥，前后矛盾的

https://github.com/python/cpython/blob/main/Python/import.c#L103C12-L103C12 单独加锁了呗，这有啥复杂的，有单独的 import 锁，并且属于整个解释器的，所以并不能并发 import

好像 golang 的 goroutine 调度并不是平衡调度，所以并发很高接口提交速度这么快的话，消费不足肯定导致大量数据拥塞在内存中内存使用量肯定高了，不过你可以试试看其实应该没有一直涨，看你这量不平衡导致内存使用估计得接近 10G 级别了吧，线程的调度平衡性要好的多，但是量特别大也是要考虑线程调度的平衡性影响的

但是换个方向如果你生成业务提交数据不是一直这么高的话，内存充足无所谓的吧，否则如果一直都这么高，或者对内存使用有极度需求，那么你使用 goroutine 提交到 Kafaka 并不能提高你整个系统的吞吐，整体来看对接口延时也帮助不大，整体还是受限于内存大小和 Kafaka 写入速度，异步 goroutine 提交没啥用吧，多余了

就这量维持心肌功能都够呛，还不如快走半小时的吧，身体机能调动需要时间，你这两加起来不超过三分钟的吧，一般来说中等运动强度比如慢跑超过 15 分钟对于普通人应该可以算是基本够用还差不多，但是如果不是特意控制饮食似乎也还是达不到能控制体重的程度

@Haku #17 不可以开端口，难道也不可以开 pipe 么？还有 IPC 通信共享内存什么的吧，也没说一定要使用网络才能搞 RPC ，windows 还有更变态的直接用进程 ID 远程写进程内存然后通过内核信号量通知进程执行远程调用的

便宜的越轻型因为弹性更大，所以噪音相对更大，你看健身房大型的就好很多，不过大多都超 5000 以上了，而且必备隔音地垫了

一种是像瑜伽垫大块的整体垫在跑步机下边，吸收你脚踏的声音，第二种小块的橡胶垫，垫在四角接触地面避免刚性连接直接传递噪音，可以垫个两三层估计更好，前者吸收低频噪音，后者隔绝高频噪音，如果跑步机放阳台估计楼下就不明显了

买过小米的跑步机用了很长时间，不过这货毕竟便宜踏板弹性太大，你几乎难以控制踏板回弹不和你脚下踩不相互冲击，对膝盖脚踝的冲击要比实在水泥地还大，后面膝盖疼的不行，所以还是废弃改室外跑了，真是受不住

厂商的请求数都是后算的吧，而且也只是个统计值，否则近乎实时计算每个对象的请求数这个费用估计都得超过你存储需要的费用了吧，所以没有这功能才是正常的