其实 ddns 的公网 ip 是路由，路由开启端口转发外围可以内外不可以，其实是端口转发一般只是目的地址重写，源地址是内外的时候还需要执行源地址重写为路由 ip 才正常，可以看看路由是否支持开启 nat 回环源地址重写，不支持的话估计就是楼上说的不同 dns 了

openwrt 的话在配置端口转发高级里有个启用 nat 回环的配置，勾上就好了，不过这货似乎如果重新拨号不能自动更新，需要停用端口转发再启用端口转发一次才好，所以我都是另外再单独建一条 nat 规则执行 lan 源地址重写

从苏州搬南京，两人包括搬 1600 还行吧，这估计的需要一整天了吧，而且第二天他们很可能没活，不是每天都有活的话，单次费用高也符合市场吧，现在农村找人修个房什么的都得快 150 一天还提供吃喝了吧，城市工地大工一天最少也得 300 以上了吧，未来估计只会更贵

How to Enable Explicit Presence in Proto3
These are the general steps to use field tracking support for proto3:

Add an optional field to a .proto file.
Run protoc (at least v3.15, or v3.12 using --experimental_allow_proto3_optional flag).
Use the generated “hazzer” methods and “clear” methods in application code, instead of comparing or setting default values

@byqtxdy07 #5 好吧，你看后面一段，这个规则需要在 3.15 版本以上才有，3.12 以上需要用 --experimental_allow_proto3_optional 来开启，其它版本应该就是搜索的结果一样不支持，我们用的 3.17 所以正常了，需要的话升级以下呗，grpc 应该兼容新版本的 protobuf 的吧

@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 分钟对于普通人应该可以算是基本够用还差不多，但是如果不是特意控制饮食似乎也还是达不到能控制体重的程度