- 用 decimal 避免精度问题；
- 用 ROUND_HALF_EVEN 来做处理，可搜下 银行家舍入法；
- 涉及汇率要谨慎，设置好警报，如果哪天接口异常，可及早处理（或者设置好默认范围，正常的波对不会很大）；
- 涉及提现要注意舍入问题，避免造成金额损失；

双拼的节奏感很好，
知乎有一个说的不错，我很赞同的，就是，三键两字。


快其实是其次，主要很舒服。

@MrhuangSTR

你多抓几份看看就可以了，
位置相对是固定的。

你事先做一份已经确定不就好？如果没 map 到，再手动补上去，这个工作总能完成的。

直接这样不行？
s.attrs[attr_name] = attr_value

这种要洗干净你可以这么做。

先下下来，随便拿一个，把表格洗了，然后字段扔进去 mapping, 如
{
"面积": parse_rule_1,
}

parse_rule_1(table, td)
td = td. next_tr.td[index]
table.pop(td)

最后如果 table 里面还有元素的话，那么就是有新的元素，直接报错。
你再手动去处理下。

但这类垂直爬取 有一个好处

你可以自己先拿几个 做个处理就干净很多。
比如你判断 “面积” 为 label 的时候，通过对比，知道一般他是在下一个 tr 里面，你写 parse 的时候，就把 2 个 tr 合起来，
直接默认拿 tr_1.td_1: tr_2.td_1, tr_2: td_2

应该是没有通解办法，

用 table 做的时候，他们都是直接怼进去 td 里面。

有个办法你可以尝试下, 你先做一个判断是不是标题的函数, 然后扔进去解解看。
比如最后带 ":" 判断为 label。

但实话说，我觉得这个很难洗干净，至少不是一下子能洗干净。

套路大概是这样, 先构建结果集，然后在结果集里面去构建。
[
[0, 1, 2, 3],
[4, 5, 6, 7],
[8, 9, x, x],
[x, x, x, x],
]

抽象看成 rand(x) --> rand(y)

2 - 4 - 16


rand(3) --> rand(10)
3 - 9 - 81
去掉[9][9]那么概率是一样的。

不是一套，

一般是先自己搭个框架，
像这种，可以分别写 爬取机制 + 清洗机制(parse )，然后做入库。



像 v 站一个老哥的，pyspider 用来做这玩意就还不错。

看需求，
比如总金额固定，最简单的就是你事先生成 数组，你自己按比例配进去；

还有一种比较简单的，就是你划定好区间，随机生成一个数，然后用二分插入的算法做。
x = [1, 100, 300, 400 ... 9990, 10000]
y = [1, 2, 3 ... 100]

index = bisect_search(x)
y[index]

不过看了你发的这几个贴。。。实际上搞个 tuplename 就算了，

class FrozenDict(dict):
def __setitem__(self, key, value):
raise TypeError("'FrozenDict' object does not support item assignment")


frozen_dict = FrozenDict


你要的是这样？

https://github.com/slezica/python-frozendict

也有这样的库，可以参考下实现

可以考虑写个

继承 dict, 复写 __setitem__

| 但是我的疑问来了。那么这个 key 是不是任何人拿到了都可以通过验证？服务端提前生成了 key，所以没办法在过期日期前让 key 失效？ 所以失效的办法只有更改服务端的加密算法，让所有的 key 都失效而达到目的？


鉴权的值只要拿到都是可以通过验证的。

需要在过期前让其失效，那么办法就是像 @justfindu 说的 做多一个 blacklist
但一般不要存 token 进去，而是解开后像校验日期一样，校验某个 unique key,

这里是为了防止某些人恶作剧，生成 N 个 token，然后可以塞爆。


----

一般也不改加密算法，你说的倒有可能是改 seed。
但一般不这么做。

其实没必要纠结形式。

鉴权 (authentication) 的本质是知道请求是谁，
这个过程大概就是 request - authentication - response。

你 request 方式是没关系的，你从 header 进来，从 cookie 进来，从 params 进来，从 body 进来，目的只有一个，就是让服务器可以知道你是谁。

比如你说
| 1.登录后，账号，密码（加密）放 cookie 里 [不安全不推荐]
你可以假设服务器有个函数为: auth_with_username_and_password(username, password) -> bool
只要为 true，那么证明账号密码都是对的，只要这一步成功，那么就把这个鉴权信息放在上下文 (context) 那么这个过程就可以继续传递下去

|2.登录后生成一个 sessionId 放到客户端 cookie 里。只放 session 的话 不保险（资源和重启服务），所以要 session + Redis

这个我感觉有些人云亦云了，
你可以当成是解耦的过程，
auth_with_username_and_password(username, password) -> str

这个 str 可以有 2 种返回方式，
一种直接通过 response 返回，你拿到 str 之后前端存到哪也是没关系的，反正用的时候带上；
一种是通过 set-cookie 的方式，直接把这个写进 cookie 里；

那么 auth 的方式就是通过
[auth_with_username_and_password, auth_with_session_id]

auth_with_session_id(session_id) -> bool

auth_with_session_id 这里怎么存都是没关系的，
你存数据库，存 redis，存本地文件都可以，只要拿得到并且有效就可以。

这个东西好处是，避免明码泄露账号密码，但 session 漏出去也是一样的。


| 3.jwt ???
一般说 有状态，无状态，这里你可以理解 jwt 无状态，是指
jwt 已经包含了主要的鉴权信息
jwt 的 j 也表明了是一个 json 结构，再做一层 decode 操作

这里跟 2 比的好处是，无论你 session 放哪，你去到服务器有一个查询的操作，
你用 jwt 的话，那么只需要解密+校验有效期就可以了。

那么 auth 的方式就是通过

auth_with_username_and_password(username, password) -> str

auth 方式可为
[auth_with_username_and_password, auth_with_token]

auth_with_token(token) -> bool

====

所以你可以把这个过程看成解耦 + 安全 + 优解。

至于用 redis 和 用其他去做，都是优化
你就算记在本子里，每次用户登录，你从本子找，然后发现对应上了，就通过，那么是一样的，无非用户需要等你慢慢找。
所以怎么判断，其实就是 f(x) 有没解的过程。

@victoriazy

哈哈哈，这个确实需要展开

抄类型。比如 flask 的时候，那时候很火抄了做个问答，类似知乎的，你也去抄，但我不知现在流行抄啥。


然后抄的过程，有几个学习点

- 看大家是怎么搬砖的，比如用到了什么框架，用到了什么第三方库，用到了什么特性；
- 看搬砖流程一般怎么搬，比如 git 怎么协作，比如前后端怎么配合，比如 bug 怎么调试
- 然后还有一个就是 web 入门比如简单一些点，要求你 crud 怎么操作，你要去的公司对你的要求怎样


然后怎么说呢，进这个地方做好心理准备，用心搬砖掏粪，没那么好搞，也不可能一上来那么多高新尖能让你搞。
还是要继续努力。